Bound stale-claim recovery waiting for unfinished runtime disposal #4106

Follow-up to #4045 and review discussion on #4063. Establish a bounded completion contract for stale-claim recovery when a runtime owner load never settles.

Boundary and required behavior

The composed gateway attempts loaded owners immediately and also shuts down late-loaded owners. Its shutdown(): Promise<void> must remain pending until all owner loads and shutdowns settle; skipping pending loads or reporting success after a race would falsely confirm cleanup. The daemon already bounds its wait and reports platformOwners: pending.

The owner-scoped stale-claim recovery caller awaits gateway.shutdown() directly. Durable recovery authority acquisition can return after its deadline or cancellation while an underlying gateway.bind/owner load remains in flight. Consequently, final disposal can outlive the acquisition deadline. This is a source-traced liveness risk, not a reproduced production incident.

Keep the fix at the caller's recovery budget/outcome boundary. Determine the contract before implementation: bounded waiting must keep the claim, preserve any earlier retained reason/primary failure, and keep late owner shutdown and its rejection observed. Do not add a silent success fallback, abandon late cleanup, allow device fallback, or weaken the gateway's terminal lifetime guarantee.

Observable completion

• In a disposable checkout at a named SHA, demonstrate acquisition deadline/cancellation followed by a never-settling owner load through the composed recovery path. Record which wait remains pending.
• Specify the recovery budget owner and typed timeout/retained result. Distinguish wait expiration from confirmed cleanup.
• Prove bounded caller completion and byte-identical retained claim; successful loaded owners must still close promptly.
• Release a delayed owner and prove it shuts down at most once, cannot bind after close starts, and late failure is observed without replacing the earlier outcome.
• Prove the regression with a controlled revert and run serialized exact-head affected validation.

Dependencies and limits

Use #4063's terminal gateway semantics as the baseline; rebase on its merged result before implementing overlapping changes. No new gateway timeout or completion result is approved by this diagnostic issue. This issue remains needs-triage until the bounded recovery contract is decided. It does not establish that existing entrypoint timeouts (#4086) have this cause.