fix(review): claude-code subscription-CLI hangs/times out repeatedly (4,030 Sentry events, ongoing)

[JSONbored]

Summary

The subscription-auth claude-code CLI provider hangs and times out repeatedly and continuously — 4,030 combined events across 4 grouped Sentry issues, 12 days ongoing as of filing, still firing.

Evidence (Sentry)

• GITTENSORY-K — selfhost_ai_provider_failed: subscription_cli_timeout, 2,068 events, first seen 2026-06-29, last seen 2026-07-10.
• GITTENSORY-M — selfhost_ai_providers_exhausted: subscription_cli_timeout, 1,568 events, same window.
• GITTENSORY-8 — ai_review_provider_exhausted: subscription_cli_timeout, 313 events.
• GITTENSORY-Z — ai_review_provider_unparseable_exhausted: primary=claude-code, fallback=claude-code, model=claude-code, attempt=2, 81 events.

Representative event context (GITTENSORY-K): timeoutMs: 180000, provider: claude-code, model: claude-sonnet-5, real PRs affected (e.g. pullNumber: 4776, repoFullName: JSONbored/metagraphed).

Root cause (Sentry Seer, needs independent verification)

Seer's summary: "Add a first-output deadline to the codex subprocess so hung API calls are detected and killed early, well before the 600s overall timeout." The per-event tag shows a 180s inner timeout but Seer references a 600s outer timeout — suggesting a two-layer timeout where the subprocess can hang with zero output for the full outer duration before anything notices. Verify this discrepancy against the actual subprocess-spawn code before trusting the summary — Seer has been unreliable on other issues in this triage (see GITTENSORY-15, GITTENSORY-D).

Separately, GITTENSORY-Z shows primary=claude-code, fallback=claude-code — if a repo's AI-provider config genuinely has claude-code configured as its own fallback, a systemic claude-code outage (like this one) has no real fallback at all. Worth confirming whether this is a real, common misconfiguration or an edge case for one repo.

Requirements

1. Detect a hung claude-code subprocess (no output progress) well before the outer timeout elapses, not just at the outer deadline.
2. Confirm whether the two-timeout (180s / 600s) relationship is intentional and correctly wired, or a bug in itself.
3. Investigate whether any repo's provider config has a real provider configured as its own fallback, and whether that should be prevented at config-validation time.
4. Do not weaken the timeout in a way that makes a genuinely-slow-but-working response look like a hang.

Deliverables

• Code fix (with a regression test reproducing a hung-subprocess scenario).
• Confirmation (via code read, not assumption) of the 180s/600s relationship and whether it's correct.
• A decision (documented in the PR) on whether same-provider fallback should be blocked at config validation.
• Verify via Sentry (or Loki) after deploy that the event rate drops to near zero within a day.

[linear-code]

JSO-3611