fix: recover Kiro intents after quota exhaustion and lost sessions

[JWThewes]

An existing Kiro intent can remain stuck after a credit outage even when its key has been replaced: a parked stage may lack a saved session, and an answer arriving before callback binding can be mistaken for a conflicting callback owner.

This change:

• Handles answers that race engine/stage callback binding, while retaining callback ownership checks and fencing retired engine runs.
• Rejects Kiro parks without a captured session and successful configured store persistence. A legacy parked stage with matching gate ownership can start a fresh conversation using its saved context and answer; reset, sibling and expired waits remain protected.
• Classifies explicit credit exhaustion separately from invalid credentials and transient throttling, with guidance and a settings link for the intent's pinned credential scope. Regression coverage verifies that rotating that scope takes effect in the same intent.
• Uses consistent recovery and unit-plan reads, surfaces storage failures separately from absent state, and documents export, stage retry and the limits of parallel repair.

Validation: 1,984 backend tests across the agentcore, v2-orchestrator, shared and intents projects pass on Node 24, including durable-runner race/replay and real Git integration tests. All 56 intent-page tests pass, as do frontend typecheck, staged formatting/lint/secret checks and the intents/orchestrator bundles. The commit hooks also pass (959 affected tests; both production dependency audits report zero vulnerabilities). Rebased without changing this patch onto main's separate checkpoint IAM fix #465; its regression test passes.

The reported production sequence is not verified because deployment state was unavailable. A genuinely mismatched approved unit plan still requires operator reconciliation. Provider balance alerts, in-flight configuration refresh and complete diagnostic backups remain separate follow-ups.

Fixes #463.

[jeromevdl]

Calling recoverLostConversation() here sets demotedResume = true. Later, line 2004 restores the durable Kiro store only when !demotedResume, because demotion previously meant that the store was known to be lost.

In this new path, however, we only know that the session ID is missing; the durable store may still exist. After a container restart, this can start with an empty local store and persistKiroStore() will replace the durable store, potentially deleting other Kiro sessions.

Please distinguish “missing session ID” from “store confirmed lost” and restore the existing store before starting this fresh conversation.

[jeromevdl]

This helper can be reached after updateStageState has already failed. Both cleanup writes are awaited without error handling, so if the same DynamoDB outage continues, runStage throws before reaching fail(...). run-stage-start then reports the generic stage_job_crashed reason instead of
stage_park_persist_failed.

Please make these cleanup writes best-effort (catch and log each failure) and always return the original structured failure. A regression test should cover the park write and subsequent cleanup writes all rejecting.