fix!: dependency floors that let dg update skip this release, and exit-code + error-stream correctness

[GregHolmes]

Blocks #100 — merge this first, then let release-please regenerate the release PR as 0.3.0.

What this fixes

1. dg update on pip silently doesn't deliver the release (root pyproject.toml).
Root declared floors as low as >=0.0.1, and pip's default only-if-needed upgrade strategy leaves any sub-package whose installed version already satisfies its floor. Measured from published deepctl==0.2.26 with the release wheels available: only 4 of 17 released packages upgraded; dg --version reported the new number while the keys fixes — including the -o json fix that headlines the release — never arrived. (uv resolves fresh and is unaffected, so the same dg update lands two users in different states.) Floors now match the versions being published.

2. Eight packages can import a symbol their declared core floor doesn't guarantee (packages/*/pyproject.toml).
deepctl-cmd-{billing,keys,members,models,projects,read,requests,usage} import get_status_console (new in core 0.2.16) at module scope while declaring deepctl-core>=0.1.10. PyPI's latest published core is 0.2.14, so pip install --upgrade deepctl-cmd-keys alone reproduces a broken CLI: the command vanishes and the ImportError prints to stdout. Same class of hand-bump as #92; release-please has no cross-package dependency automation, so these floors are hand-maintained.

3. A crash exited 2 — the code reserved for user interrupt (src/deepctl/main.py).
Per the published contract (0 = success, 1 = error, 2 = user interrupt), main()'s generic exception handler now exits 1. Because cli() runs with standalone_mode=False, Click usage errors (bad flag, unknown command, bare dg) propagate to this same handler and move from 2 to 1 as well — consistent with the contract, which reserves 2 for interrupt. Also repairs three tests whose patch.object(cli, "__call__", ...) was inert (dunder lookup bypasses instance attributes) and adds a usage-error exit-code test.

4. …but that alone demoted a real Ctrl-C to 1 (src/deepctl/main.py).
With standalone_mode=False, Click catches a KeyboardInterrupt raised during command execution and re-raises it as click.exceptions.Abort — a RuntimeError subclass, not a KeyboardInterrupt. In this repo the path is more direct still: BaseCommand catches the interrupt itself and raises click.Abort(). So a mid-command Ctrl-C — the common case — bypassed the KeyboardInterrupt handler entirely and landed in the generic handler that 3 just changed, exiting 1 and printing an empty Error: (str(Abort()) is ""). Before 3 that path exited 2 correctly by accident. Abort is now caught alongside KeyboardInterrupt, so user cancellation (Ctrl-C, Ctrl-D at a prompt) always exits 2, with a test on the Abort delivery path.

5. Root diagnostics printed to stdout, corrupting -o json (src/deepctl/main.py).
main()'s module-level console was a plain rich Console(), which writes to stdout, and both of its handlers print through it — so a crash, bad flag, unknown command, or bare dg wrote human-readable prose to stdout. dg -o json not-a-command put Error: No such command ... on stdout and left stderr empty, so anything piping stdout into jq parsed the error text instead of JSON. This is the root-handler half of the #97 sweep: that issue's scope covered moving errors to a stderr console "so stdout stays clean", and #101 closed the sweep, but both only ever reached the command layer. Now aliases deepctl_core.output.stderr_console — the same console print_error() writes to, and the pattern deepctl-cmd-mcp already follows — so root-level and command-level diagnostics format identically, including the no-color handling for agentic/CI callers. Exit codes are unchanged and success paths still write their payload to stdout. Adds tests asserting a failing dg -o json ... writes nothing to stdout (unknown-command and bad-flag paths) and that the cancellation notice is on stderr.

Why the BREAKING CHANGE footer

The exit-code enforcement (#101) landed as fix:, so release-please would ship it as patch 0.2.28 with no version signal — and #100 currently confirms that: root reads 0.2.28 and its diff contains no ⚠ BREAKING CHANGES section at all. There is no machine-readable breaking marker anywhere in the cycle; the behavior change exists only as hand-written prose in 21b8333 / e327a5e. The break belongs to #101's already-merged code, so it cannot come from a conventional-commit type on this PR's own diff — it has to be injected where the version arithmetic can see it. With bump-minor-pre-major, that makes root 0.3.0.

The signal is deliberately stated in three places, because which one release-please actually reads depends on how this PR is merged:

• BREAKING CHANGE: footer on 914e132 — the primary. That commit touches only src/deepctl/main.py and its tests, i.e. a root-only path, so the break is attributed to root alone and the eight sub-packages stay patch bumps. This is the one that survives a merge commit, and it is the only variant that produces the intended release shape.
• fix!: in the title — insurance. This repo's recent PRs were squash-merged, and with squash_merge_commit_title: PR_TITLE / squash_merge_commit_message: PR_BODY a squash discards every commit message, footer included. The ! keeps root at 0.3.0 in that case.
• BREAKING CHANGE: footer at the foot of this description — so a squash also carries the descriptive text into the ⚠ BREAKING CHANGES section rather than just the subject line.

Trade-off to know before merging: prefer a merge commit. A squash collapses all five commits into one that touches root and the eight packages/deepctl-cmd-*/pyproject.toml files, so the break gets attributed to those eight paths too — they would take minor bumps (keys 0.0.3 → 0.1.0, usage 0.1.13 → 0.2.0, …) with a breaking-change entry about CLI exit codes that has nothing to do with them, and root's floors here (>=0.0.4) would then sit below what actually published, re-seeding the staleness this PR exists to fix. Root reaches 0.3.0 either way; only the sub-package shape differs.

After merge — steps on the regenerated #100

1. uv lock and commit (version bumps stale the lock; CI runs uv sync --locked — this is the eff5291 wall and recurs every release until release.yml regenerates the lock itself).
2. Re-apply the behavior-change prose (git show 21b8333 e327a5e), changing 0.2.26 to 0.2.28 → 0.2.26 to 0.3.0, and fold in the exit-code and output-stream details from this PR: crashes and usage errors move 2 → 1, 2 stays reserved for user interrupt (Ctrl-C during a command still exits 2), and root error/cancellation output moves from stdout to stderr. Decide there whether the stream move gets its own ⚠ BREAKING CHANGES line or reads as a plain fix — root lands on 0.3.0 either way, so it is a notes-wording call, not a version call.
3. Verify root reads 0.3.0 across manifest / pyproject.toml / __init__.py / CHANGELOG heading, and the ⚠ BREAKING CHANGES section renders the footer text.

Verification here: full suite 1094 passed / 6 skipped; make check clean (ruff + mypy, 115 files); uv lock --check clean after both floor commits; live probes — --version → 0, bare dg → 1, bad flag → 1, unknown command → 1, mid-command Ctrl-C → 2; dg -o json not-a-command writes 0 bytes to stdout with the error on stderr, while dg -o json models still emits valid JSON on stdout.

🤖 Generated with Claude Code

BREAKING CHANGE: dg now exits non-zero when a command fails: 1 for
errors (including crashes and usage errors), 2 for user interrupt, 0 on
success. Every command previously exited 0 regardless of outcome, so
scripts and CI steps that ignored the exit code will surface failures they
were silently swallowing. No command that succeeds changes its exit code.