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.

Thanks for the thorough review. Good catch on the nullability audit.

I grepped for all callers of loadMostRecentChatState across the codebase (excluding test files). There is exactly one production caller: use-send-message.ts line 177, inside the continueChat useEffect. Here is how it handles the null case:

const loadedState = loadMostRecentChatState(continueChatId ?? undefined)
if (loadedState) {
  previousRunStateRef.current = loadedState.runState
  setRunState(loadedState.runState)
  setMessages(sanitizeRestoredMessages(loadedState.messages))
  if (loadedState.chatId) {
    setCurrentChatId(loadedState.chatId)
  }
}

• previousRunStateRef is typed RunState | null, so assigning loadedState.runState (now RunState | null) is safe.
• setRunState accepts RunState | null (it comes from the chat store which already supports both).
• The outer if (loadedState) guard means we never reach these lines when the whole state is null.
• The nullability change in SavedChatState.runState is specifically documented in the type comment at line 27: "Null when nothing usable was persisted (a run-state without sessionState is never adopted)."

The other references to loadMostRecentChatState are in run-state-storage.test.ts (unit tests that already exercise the null path) and in eval fixture diffs (not real code).

Also rebased the branch on latest upstream (170+ new commits) and resolved the 3 merge conflicts (use-send-message.ts, helpers/send-message.ts, use-send-message.test.tsx). All clean.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.