Fix orphaned model-wait subagents so Stop unblocks the awaiting parent

[Hmbown]

Summary

A delegated child can remain Running in model_wait after a Responses API request fails, leaving the parent indefinitely at delegate waiting · subagent.

Observed in v0.9.0

• One child completed normally, while a second visual-review child remained at a before_api_request checkpoint in model_wait.
• Its transcript ended with a Responses API request failure but no terminal completion/failure event was recorded.
• The parent could not fan in and continued waiting.
• The Stop UI is a two-stage confirmation (second click or Enter within the arm window), but an orphaned child can remain non-terminal after confirmation.
• On restart, persisted top-level Running agents are converted to Interrupted, but the independently loaded worker ledger can retain a non-terminal model_wait record. The UI can therefore continue to show a ghost active worker.

Expected

• A failed or cancelled child must reach a terminal state exactly once.
• Parent waiting must be bounded and wake with an actionable cancelled/failed result.
• Preserve the checkpoint for retry/resume, but never leave an orphan marked running.
• Reconcile restored worker-ledger state with the restored agent terminal state.
• Make the two-stage Stop confirmation and final cancellation state unambiguous in the UI.

Suggested work

Audit the work-surface stop/confirmation flow, request lifecycle, and restart restoration. Add regression coverage for a child that fails while awaiting a model request, then receives cancellation and is restored after an app restart.

Relevant areas: crates/tui/src/tui/work_surface/interaction.rs, input.rs, subagent state persistence/reconciliation.