Fix owner-gate Composer continuation recovery

[IUnknown404I]

Summary

• atomically promote an already-queued explicit Composer successor when its predecessor exhausts transport retries
• reconcile the same stranded successor after restart without creating a replacement turn
• persist truthful resource/runtime queue reasons and keep admission deferrals out of the transport-failure budget
• retain narrow, provenance-bound disk-only RED recovery for an explicit resident owner-gate continuation
• expose resource/runtime recovery waits in the API/UI and update all supported public docs

Safety

• provider capacity and non-disk RED remain fail-closed
• owner-gate recovery requires same-terminal durable provenance
• Inbox callbacks and Exited terminals are never reopened by successor reconciliation
• logical turn, receipt, provider lease, and workflow-effect exactly-once fences are unchanged

Checks

• 288 focused lifecycle/capacity/API/UI-read-model/terminal tests passed
• 43 operations tests passed; the host-RED-only wrapper exit-status test was excluded because its subprocess intentionally uses ordinary RED admission
• 51 Web status tests passed
• TypeScript tsc --noEmit passed
• focused mypy passed
• Black and diff checks passed
• localization validation passed for 7 locales / 192 translations
• docs bundle check and public-surface audit passed
• isolated migration/reconciliation rehearsal against a backup of the affected durable state promoted the exact queued successor without creating a turn; SQLite integrity remained ok

Closes #64