fix(app): recover from a silently dead event stream

[Luppa90]

Issue for this PR

Closes #39352

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fixes the web UI freezing mid-session: the spinner keeps spinning, the timeline stops, and only a page refresh reveals the run finished long ago.

A dead event stream is undetectable. The SSE consumer reads the response body with no timeout, so a socket that dies without a FIN/RST parks reader.read() forever — no error is thrown, so the reconnect loop in server-sdk.tsx is never re-entered. Heartbeats can't help, because v2 sends them as SSE comment frames which the parser discards without yielding an event, leaving liveness invisible at the event level. So this tracks the stream at the byte level (comment frames included) via a fetch wrapper, and a per-attempt watchdog aborts after 45s of silence, dropping into the existing reconnect path. The watchdog aborts a controller captured per attempt, so a stale timer can't kill a healthy successor connection.

Reconnecting alone repairs nothing. session_status is written only by session.execution.* events, so a run that finishes during the outage stays busy forever, and a run that keeps going has lost the deltas its timeline was waiting on. So the client reconciles against the server on reconnect: statuses the server no longer reports active are cleared, and locally-held timelines are reloaded.

Two details in that repair are load-bearing, and both were found by a fix that looked right and didn't work:

• It is driven by the transport, not by the server's server.connected frame. The failure being recovered from is a stream that stops delivering, so a repair that waits to be told about the reconnect is exactly the one that never runs. It fires when a replacement attempt opens, before any byte arrives, and talks plain HTTP so it still completes when the replacement stream delivers nothing either. It also deliberately does not go through the active-sessions query: routing it there made it conditional on that query being idle, and a first fetch that never settles disabled the repair permanently.
• It reloads by what is held locally, not by status. bootstrapDirectory also rewrites session_status from the server on reconnect and then calls resolve(), which refreshes session info but never messages. When it lands first, a finished session already reads idle, so a status-keyed reload skips it — clearing the spinner while leaving the timeline frozen mid-message.

Sessions in retry keep their status, since retries run inside the execution fiber and the server still reports them active on both protocols.

How did you verify your code works?

• Reproduced and fixed against a live server. Console on a stall now shows the full chain: event stream stalled, reconnecting {idle: 48870} → event stream re-established, repairing state {attempt: 2} → a bare /session/status → repaired state after event stream reconnect {active: [...], resynced: [...]} → session reloads. The frozen tab recovers on its own, with no page refresh.
• Earlier versions of this repair were confirmed not to run, from the absence of that bare /session/status in the network log — the SDK only appends ?directory= when constructed with one, so the repair's request is distinguishable from the directory-scoped bootstrap calls.
• Unit tests: byte tracking includes heartbeat frames; non-stream fetches pass through untouched; statuses for finished runs are cleared; retry statuses preserved; sessions holding messages are reloaded; and a finished session whose status a racing bootstrap already reset still gets reloaded. That last one was checked against the pre-fix implementation to confirm it fails there.
• All 9 transport e2e specs pass (session-timeline-transport.spec.ts, remote-tab-busy.spec.ts), including reconnect-after-close, reconnect-after-error, and heartbeat delivery.
• bun test for the app package, typecheck, prettier and oxlint are clean. The only failing test is the pre-existing ar i18n parity gap, which fails identically on dev.

Worth stating plainly: the transport-driven trigger is verified in live use, not by a unit test — the reconnect path needs a real stream to exercise.

Screenshots / recordings

Not a visual change — the fix is that the timeline and spinner recover on their own after a dead connection, instead of freezing until a manual refresh.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍