fix(desktop): recover root boundary from transient render races

[izumi0uu]

What does this PR do?

Prevents Hermes Desktop from getting stuck on the root "Reload window" screen when assistant-ui hits a transient stale-index render race.

The root ErrorBoundary now treats a small set of known renderer errors as recoverable, logs them, and resets itself on the next tick so React can re-render against fresh state instead of leaving the whole app latched on the fallback screen.

This intentionally implements the smallest mitigation proposed in #41693 (option A). It does not yet try to reorder the underlying session / message teardown path.

Related Issue

Fixes #41693

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✅ Tests (adding or improving test coverage)

Changes Made

• apps/desktop/src/components/error-boundary.tsx: add root-only recoverable error matching for tapClientLookup: Index ... out of bounds, Cannot read properties of undefined (reading 'type'), and Tried to unmount a fiber that is already unmounted; schedule a next-tick reset(); clear pending recovery timers on reset/unmount.
• apps/desktop/src/components/error-boundary.test.tsx: add a component test that reproduces a tapClientLookup stale-index race through AssistantRuntimeProvider + ThreadPrimitive.MessageByIndex and verifies the boundary recovers instead of leaving the Reload window fallback on screen.

How to Test

1. cd apps/desktop
2. Run npm run type-check
3. Run npm run test:ui -- --run src/components/error-boundary.test.tsx
4. Run npm run test:ui -- --run src/components/assistant-ui/streaming.test.tsx -t "renders assistant text incrementally before completion"

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS (targeted desktop type-check + Vitest)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

[iizus]

Thanks for tackling this — confirming this is option A from #41693 (boundary-level mitigation). LGTM as a UX fix: users will no longer be latched on the "Reload window" screen.

One concern about scope: the underlying @assistant-ui/store@0.2.9 stale-index throw + Hermes-side session/message teardown race is still present. After this merges, [error-boundary:root] log entries, React #520 fiber-unmount warnings, and Session not found 404s will continue to fire — they just won't be visible to the user.

Suggestion: when this lands, please leave #41693 open (or split out a follow-up issue) tracking the lower layer — store throw semantics + teardown ordering — so the root cause doesn't get marked resolved by a symptom-only fix. Otherwise the race may resurface as a different symptom (frozen UI, stale message lists, etc.) under a different reproduction path.

[JakubMerkandi]

We are hitting the same crash locally, so this mitigation would be useful.

Representative Desktop log:

tapClientLookup: Index 6 out of bounds (length: 1)
[error-boundary:root] Error: tapClientLookup: Index 6 out of bounds (length: 1)
    at UserMessage

The root-boundary recovery in this PR should prevent the Desktop from getting stuck on the reload screen, which matches the user-visible failure we see.

One related debugging note: in our case the stack points through UserMessage, and the underlying race appears consistent with a stale ThreadPrimitive.MessageByIndex from the virtualized thread after the runtime message list has already changed. So this PR is a good safety net; a complementary follow-up could guard stale message indices before they reach tapClientLookup.

[OutThisLife]

Thanks for this @izumi0uu — the boundary-level recovery is the right UX fix, and your recoverable-error pattern set (tapClientLookup stale index, reading 'type', fiber-already-unmounted) matched the field reports exactly.

I've reimplemented it in #52704 with your approach as the core, addressing the one concern raised on this thread (symptom-only / unbounded): auto-recovery is now bounded — at most 3 attempts per 5s window — so a genuinely persistent error can't spin the boundary in a reset -> throw -> reset loop and instead falls back to the reload screen after the budget is spent. Manual retry resets the budget; only the root boundary auto-recovers; unrecognized errors are never swallowed. There's a regression test proving the loop is bounded (it would hang without the cap).

You're credited via Co-authored-by on the commit. Superseding here; closing in favour of #52704.