after a stale runtime-session drop (the sleep/wake 404 that resumes the
stored session and retries once), but two call sites still build their
gateway call directly instead of routing through withSessionNotFoundResume:
- session-tile-actions.ts's own cancelRun/steerPrompt/reloadFromMessage —
the tile's OWN UI handlers (wired directly by session-tile.tsx as
onCancel/onSteer/onReload), distinct from use-session-tile-delegate.ts's
interruptSession/submitToSession (used by external callers like
quick-entry-bridge), which #81261 did wrap.
- use-prompt-actions/index.ts's reloadFromMessage (the primary chat's own
"Regenerate") — it builds its prompt.submit call inline instead of going
through the shared send() helper every other action in this file uses,
so it never picked up the recovery wrapper.
After sleep/wake (the exact scenario #81261 targets), clicking Stop,
sending a steering correction, or clicking Regenerate on a tile or the
primary chat surfaces a raw "session not found" error instead of silently
resuming, even though #81261 landed the day before.
Wrap all four call sites in withSessionNotFoundResume, mirroring the
existing pattern each file already uses elsewhere (submitRewind/
syncAttachmentsForSubmit in session-tile-actions.ts, redirectPrompt/send in
index.ts) — resolve the stored session, resume once, retry, and rebind the
live runtime ref via onRecovered.
93ed11379b