[Fix] Sessions show false interruptions and lose resumable task errors

[roomote-roomote]

​Created by Roomote. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Retire inference retry markers when a recovered Fast turn ends silently, ignores an event, or responds with a reaction. Hidden notices stay hidden; a previously displayed notice is updated to say the retry completed, without claiming the delegated task completed.
• Preserve redacted stored errors and error codes in idle/resumable child settlement notifications, including interrupted review runs. Ordinary idle notifications remain unchanged, and idle errors do not grant failed-start retry controls.
• Define bounded orchestration recovery for already-authorized unfinished work: inspect current state and prior attempts, continue the same task at most once per outstanding request, and require explicit user direction after that limit. Cancellation, input/approval waits, nonretryable errors, uncertain side effects, and presentation-only events remain excluded.
• Persist task-continuation claims before delivery and restore the recovery budget from canonical receipts across Fast turns and run IDs. Recovery is the default; instruction mode requires current human input and a server-derived request identity. Only an accepted new instruction resets the task's budget. Unknown delivery remains consumed, definite rejection releases its reservation, and missing history or claim storage fails closed.

Why this change was made

Successful silent recovery could leave a marker that reconciliation later mislabeled as an interruption. Separately, idle settlement could hide an error from the parent, making accurate status and recovery decisions harder. These corrections address reporting and orchestration behavior, not the underlying provider failure.

Impact

Sessions avoid false interruption notices after successful recovery and retain meaningful error context for resumable work. The recovery budget is now enforced from persisted receipts rather than prompt text alone. Repeated task-settled events, new run IDs, and local guard resets do not grant another recovery. Explicit human instruction intent remains distinct from status checks; platform and reaction events cannot select instruction mode without an intervening human directive. No schema migration or retry scheduler is introduced. Generic provider errors are not assumed transient, and prior progress claims do not override current execution/error evidence.

Focused validation passed: 439 tests across Fast service, recovery guard, prompt, native tool bridge, and conversation repository, including real-database receipt-history coverage and a seven-turn recovery regression. The earlier idle-notification correction passed 19 targeted tests. Package TypeScript and full pre-push lint, fast typecheck, and knip gates passed. Browser proof is not applicable to these server lifecycle/payload and prompt changes. The original provider incident was not reproduced end-to-end, and this PR does not establish its root cause or fix provider availability.

[roomote-community]

1 issue outstanding. See task

• Prevent a status check from entering instruction mode and resetting the persisted recovery budget. (packages/cloud-agents/src/server/fast-agent/fast-agent-service.ts:4243)

_{Reviewed 8e816e6}

[roomote-roomote]

Fixed the cross-turn recovery-budget finding in 8e816e69 and resolved the review thread.

• Continuation claims are persisted before child delivery and restored across Fast turns/run IDs.
• Consumed and unknown recoveries remain blocked; only an accepted new human instruction resets that task's budget. Platform events cannot mint instruction identities.
• Added real-database receipt-history and multi-turn service regressions. All 439 focused tests, package TypeScript, and full pre-push gates passed.

PR metadata is refreshed and the PR remains draft. Browser proof is not applicable to this backend enforcement change. Automatic re-review is underway; this reports the pushed fix and local verification, not a completed fresh review or a fix for provider availability.

[roomote-community]

taskMessageInstructionId is set for every substantive human turn, including a status check. Because continuation is supplied by the model, a later “Any update?” turn can send continuation: "instruction"; this condition accepts it, acceptInstruction clears the persisted recovery reservation, and the next task-settled event can recover the same work again. That still breaks the one-recovery-per-outstanding-request limit. Derive the reset boundary from an actual new directive server-side rather than trusting the model-selected mode on any human message.