fix(web): retry failed thread loads

[Gigioxx]

Failed thread subscriptions left web/desktop showing “Loading messages…” even after the runtime recorded an error. Show that error in the existing banner and let Retry refresh the thread atom on the current connection. Keep the thread shell visible and sending blocked while history is missing; cached history and ordinary dismissible session errors keep their existing behavior.

Fixes #10418. Reproduced with an injected subscription failure in an isolated local web client, then verified a failed retry and successful recovery after removing the fault, without restarting the app. This confirms the stuck-loading path, not disk exhaustion as the original trigger. The temporary fault and synthetic data are not included in the diff.

Verification: 67 focused tests pass, including failed-load presentation and mounted-atom recovery with empty/cached history. Web and client-runtime typechecks pass. Scoped lint and React Doctor report existing warnings only. Web and desktop share this view; mobile, provider adapters, contracts, and connection transports are unchanged. Browser verification used the local web client, not a packaged desktop build.

Before	After

Retry recording: failure persists, then history recovers without restart

Model: GPT-6. Harness: Codex in T3 Code.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This is a focused thread-loading bug fix: failed subscriptions now show their existing error and can be retried without restarting, while normal loading and dismissible errors remain unchanged. The production changes are localized and supported by client-runtime and sync-phase tests.

Not approved because:

• Monthly spending limit reached (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more.}