Thanks for the careful write-up — the root-cause analysis on the lost turn_done is exactly right, and the Go-side panic recovery in runGuarded (plus the two tests covering emit-once-on-panic) is solid work. That part I'd take as-is.

The frontend changes need another pass before this can land, though — one of them is a hard crash:

1. The watchdog useEffect is nested inside another effect (blocker). In useController.ts the new useEffect is placed inside the body of the existing event-subscription useEffect (the one that opens with const textBatch = ... and closes with return () => { textBatch.drain(); ... }, }, [dispatchTo, ...])). Calling a hook from inside another hook's callback violates the Rules of Hooks — React throws Invalid hook call the moment that outer effect commits on mount, which takes the whole main view down. It needs to be hoisted to the top level of useController, as a sibling effect. (This is also why the symptom wouldn't show up in go test — it only fails when the desktop app actually renders.)

2. The no-deps "reset on every render" trick is fragile. Even once hoisted, an effect with no dependency array re-arms a 30s timer on every render for any reason, not just token events — so an unrelated re-render keeps resetting it and it may never fire, while a genuinely-idle-but-not-re-rendering tab fires it. Prefer tracking a lastTokenAt ref updated on token events and comparing against it, with an explicit deps array so react-hooks/exhaustive-deps stays happy.

3. open={!userClosedReasoning} regresses completed cards. With the initial state false, every reasoning card renders expanded — including finished turns and history loaded from disk, which previously collapsed via defaultOpen={item.streaming}. Derive the open state from streaming as well, e.g. keep it controlled but seed/close it when item.streaming goes false, so done turns stay collapsed.

4. Global ESC handler toggles every open card. The document-level keydown listener in ProcessCard is registered per instance, so with the reasoning card and a tool card both open, one ESC closes all of them at once — and it collides with ESC used elsewhere (cancel/close). Scope it to the focused/hovered card, or handle ESC at a single owner instead of per-card.

The diagnosis is good and the backend half is ready — fix the hook nesting first (that's the crash), then the open-state and ESC scoping, and I'll re-review.

Re-reviewed the latest push — all four points addressed properly:

1. The watchdog is now a top-level sibling effect with a real dependency array; the lastTokenAt ref + remaining-time timer is exactly the shape I asked for, and re-arming off activeState.live means token flushes naturally reset it while a stalled stream still fires after the full 30s.
2. Covered by the same rework.
3. useState(item.streaming) as the controlled seed keeps history/finished cards collapsed on mount while letting the user close a stuck one — which is the original #3746 symptom.
4. ESC now lives on the header button's own onKeyDown, so it only acts on the focused card and can't collide with global ESC semantics.

The Go-side panic recovery in runGuarded plus the emit-once tests were already solid in the first round. Nice turnaround — merging.