fix(web): connect refusals reach the caller

[cvince]

The last file in the refusal class — and I was wrong that it needed a decision.

I reported connect as not-contained because execute returns Promise<{ linked: boolean }> and recurses into itself, so wrapping it in a handler returning never would change the contract. That was the wrong shape to reach for. rotateCommand already documents the right one, and it wraps nothing:

await refuse(…); return; at every call site, and the return is not decoration: displayErrorAndExit is Promise<never> but TypeScript does not narrow across an awaited never

Called directly and followed by return { linked: false }, the signature is untouched and the recursion is untouched.

refusal	code
dev-mode live firewall (×2)	PERMISSION_DENIED
unknown provider	INVALID_FORMAT

The unknown-provider case is the one reachable under --web: the browser picker is offered first, and this is where the run ends when the picker is declined or cannot be shown — previously on a stream with nobody on it.

The firewall sites are dev-binary only, but capy-dev --web --live reaches them, so they get the same treatment. Nothing about the refusal is weakened: same condition, same exit code, one more surface it reaches.

capy-cli now has zero bare console.error + process.exit(1) refusals in the command layer that are reachable under --web.

Suite: 1851 pass, 0 fail.

[cvince]

Status, since chat replies are not arriving

You read #343's diff in detail, so PR content reaches you. Chat does not. Posting here instead.

capy deploy --web — run again just now (9th run)

Nothing blocks it. No staging project dir, no keep.lock, no credentials, no deploy target. Clean temp HOME, ~40s.

COMMAND:   capy-staging deploy --web
EXIT CODE: 1
URL LINE:  http://127.0.0.1:58291/s/-XdniUBYsWb1cmCFidkIrj4EuVycR49P-l1G8K4mTgo

Earlier run additionally fetched the page: HTTP 200, 68,286 bytes, containing the refusal text — so it is real content, not an empty shell. Full evidence with timestamps and SHAs: ~/.capy-e2e-overnight/evidence/deploy-web-url/RESULT.md, and #343's comment thread.

The refusal class is finished

Your last three messages listed kick, org, transport, edit, recover, connect and the deployTokenCommand classes as open. They are merged. Verified against the tip by content, not memory:

file	bare exits reachable under --web
kick, org, transport, edit, connect	0
recover	0 reachable — 5 remain after if (options.web) return, unreachable by construction
deployTokenCommand	2 remain, both double-print cases (below)

Merged: #334, #335, #338, #339, #340, #341, #342, #343. This PR (#344) is connect, the last one.

Skip paths

• checkoutCommand:377-398 — done in fix(web): two skip paths that completed without ever reaching a browser branch #343
• capyCommand:262-309 — done in fix(web): two skip paths that completed without ever reaching a browser branch #343 (needed no signature change; this.options.web was already on the instance)
• orgCommand:253-256 — done in fix(web): route org and transport refusals through the error screen #335
• endRecoverCommand:83-86 — not done, and I will not do it unilaterally. WebEndRecoverParams.session is REQUIRED by design; the type comment says a page served without one "would let a click unlink files the terminal form would never have touched — and every row on it arrives ticked, which makes that the DEFAULT answer rather than an opt-in." Serving it satisfies the URL rule by reintroducing a plaintext-deletion bug. It needs an informational screen (no rows, nothing destructive) through workbench with approved copy.

Genuinely remaining

Four double-print cases — 2 in inviteCommand (role-grant refusals), 2 in deployTokenCommand (mintOrExit after spinner.fail, ambiguous-prefix concatenation). Each already has its message on screen before the exit, so converting prints it twice. Folding the existing output into the throw is a copy decision, not a mechanical edit.