Prove installed Railiance runtime recovery under worker failures

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e387-534d-70e3-ad53-4ea05676db8c

workplans/REINAH-WP-0003-governed-runtime-integrity.md

@@ -879,3 +879,40 @@ the contract gate (`169 passed, 1 skipped`) and recovery gate (`131 passed,
 runtime packages. All sibling imports and exact source-lock checks pass. The
 proof script parses and its isolated installed-package `--help` succeeds.
 State Hub readback confirms the plan is `blocked` and T05 is `wait`.
+
+### Installed host recovery return — 2026-09-27
+
+Resumed T05 at the user's request. Added `scripts/prove-runtime-recovery.py`
+and exercised it on Railiance with the installed `b6e4e8a4` runtime's isolated
+interpreter, exact artifact digest and profile `harness.agent-dev-local@1.1.1`.
+All four packages came from the immutable artifact. The standing worker stayed
+active and no production queue, provider or credential operation was performed.
+
+The real worker/Glas/bwrap/transaction path passed six drills:
+
+- A lost close response replayed the same durable intent from a reopened
+  outbox, with one execution, one accepted commit and one metrics record.
+- A sandbox child exiting 7 produced a durable failed close, clean unchanged
+  source, released lock and destroyed sandbox.
+- Periodic heartbeat rejection cancelled execution; a deliberately returned
+  late sandbox commit was not imported and no terminal close was attempted.
+- A real SIGTERM through `run_claim_loop` rejected a late commit and durably
+  failed the run after cleanup.
+- SIGKILL of a lock holder released its kernel lock after cross-process
+  contention had first been verified.
+- SIGKILL of the disposable worker after sandbox creation left its ownership
+  record available for explicit sand-boxer destruction. Owner recovery removed
+  the workspace, released the repository lock and retained the clean baseline.
+
+Receipt: `docs/evidence/2026-09-27-installed-runtime-recovery.json`; operational
+instructions are in `docs/ops-run-claim-loop.md`. This closes the missing
+installed-host mechanism drill, including explicit hard-crash cleanup. It does
+not claim automatic orphan sweeping or live Activity Core lease expiry.
+
+T05 remains `wait` on admitted native credential/spend operation and natural
+queue/lease recovery evidence. T04 still requires tenant replacements and
+cutovers; FI additionally requires its agreed publication contract and five
+weekday canary results. T06 still requires the attended native requester/human
+approval and fresh spend/window described by the existing metered proposal.
+Those are existing owner gates; no new task/workplan or substitute approval
+has been created, and the workplan remains `blocked`.