Fix blank-session restarts after interrupt or failed run

[bunnysayzz]

Fixes #1054.

Root cause

The CLI only synced previousRunStateRef (the continuation state passed to the SDK as previousRun) when client.run() settled. But Esc releases the input lock immediately, inside the abort listener. So a follow-up message sent the moment the user hits Esc could be built from a stale (or null) ref. With a null ref the SDK builds a fresh session state and the chat comes back as an empty, brand-new conversation, which reads exactly like a hard reset.

Two more holes in the same family:

1. The thrown-error catch path (failed/expired runs) never synced the ref, only disk, so the next prompt in the same process also lost history.
2. A sessionState-less run state could be persisted and then adopted on restart (loadMostRecentChatState fabricated { output } when run-state.json had no session state), poisoning every resumed chat.

Fix

• setupStreamingContext accepts an onAbort callback, invoked synchronously at the top of the abort listener, before the input lock is released. useSendMessage passes syncRunState(latestRunStateSnapshot) so an interrupt checkpoints the latest SDK snapshot immediately.
• useSendMessage now owns a generation token per admitted run. A superseded run settling late can never adopt state, persist a checkpoint, or touch shared queue state over the run that replaced it (also gated handleRunCompletion/handleRunError/finally with it).
• The catch path syncs the ref too, then persists, so a failed turn resumes from the last snapshot.
• loadMostRecentChatState treats a run-state without sessionState as unrestorable; the transcript still restores, the agent context does not.

Tests

• New hook-level suite cli/src/hooks/__tests__/use-send-message.test.tsx drives the real wiring (createRunConfig + a controllable client via a small DI seam, matching the repo documented DI-over-module-mocking approach): abort-then-follow-up carries full history, a superseded run settling late cannot clobber the newer run state, rejected runs resume from the last snapshot, and sessionState-less states are never adopted.
• Helper tests cover the onAbort callback contract (sync ordering before lock release, throwing callback still cleans up).
• Storage tests cover the load-side poison guard.

All targeted suites pass (92 tests). Typecheck, prettier, and git diff --check are clean; the app bundle builds.

[codebuff-team]

Nice work here. The root-cause analysis is correct and the fix addresses three real holes: the abort listener releasing the input lock before previousRunStateRef is synced, the thrown-error catch path never syncing the ref, and loadMostRecentChatState fabricating a sessionState-less run state that later poisons a resumed session. The generation-token guard (runGenerationRef/runIsCurrent) is the right mechanism to prevent a late-settling superseded run from clobbering newer state, and gating handleRunCompletion/handleRunError/the finally block on it is a good catch beyond the original bug report.

The test suite in use-send-message.test.tsx exercises the real wiring through a DI seam (setClientFactoryOverrideForTesting) rather than mocking modules, which matches the repo's stated approach, and covers the four scenarios described in the PR body directly.

One thing worth double-checking before porting: SavedChatState.runState changes from RunState to RunState | null in run-state-storage.ts, and loadMostRecentChatState can now return runState: null where it previously always returned a fabricated object. That's the correct fix for the poisoning issue, but every caller of loadMostRecentChatState in the actual (non-mirror) codebase needs to be audited for non-null assumptions — this diff only shows the CLI hooks/tests, not every consumer. Please confirm (or note in the PR) that you grepped for other callers.

Overall this is exactly the kind of bug fix I'd want ported: precise diagnosis, minimal collateral change to non-test code, and tests that would have caught the regression. Recommend a maintainer verify the nullability change doesn't break other call sites, but the core fix looks solid.