fix(web): recover stale response streams

[sam-saffron-jarvis]

Summary

• bound response-stream connection establishment so a replacement SSE request cannot remain pending before headers forever
• adopt the authoritative server epoch from the initial response.created event instead of aborting every admitted POST into snapshot recovery
• reconcile stale mobile run projections from authoritative idle status plus the durable transcript, including after the five-minute response snapshot expires
• bypass conditional status caching during authoritative focus/visibility recovery

Root causes

The mobile failure was a chain of three independent holes:

1. Replacement event streams had an unlimited pre-header wait; the existing inactivity watchdog only began after fetch() returned a response.
2. New local projections started with epoch 1, while the server emits a generated run epoch. The first response.created event therefore caused an epoch mismatch, aborted the original WebRTC POST, and forced every response through snapshot recovery.
3. If iOS missed the terminal event and the response snapshot aged out after five minutes, a 404 was treated as a retryable transport failure. The server session was idle, but the stale local projection remained the UI authority and displayed Working / Running a command indefinitely.

Behavior

An authoritative status sample that began while the same projected response was active can now reconcile an idle server through the durable transcript revision. Once that revision is installed and the session remains idle, the stale projection, transport lease, and supervisor are retired. A newer run or an uninstalled transcript revision prevents retirement.

Verification

• mise x node@24 -- npm test — 408 tests passed
• mise x node@24 -- npm run typecheck
• mise x node@24 -- npm run lint:ts
• production frontend build via mise x node@24 -- make build
• deployed locally and confirmed on the affected iPhone with one-minute tool-call responses; Working now clears