Block RMASTER-WP-0020 until T08 cleanup gates open

Park the OpenBao migration workplan as blocked and T08 as wait. Retention,
the post-cutover disaster-recovery drill, and explicit destructive-deletion
approval are all still closed; do not reopen before 2026-08-17.

workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Migrate authoritative OpenBao from CoulombCore to reef-railiance"
 domain: financials
 repo: railiance-master
-status: backlog
+status: blocked
 owner: codex
 topic_slug: railiance
 created: "2026-07-30"
-updated: "2026-08-04"
+updated: "2026-08-14"
 depends_on:
   - NK-WP-0022
 state_hub_workstream_id: "0616a297-18c5-4c4e-a4fc-69135b3f9a15"
@@ -237,7 +237,7 @@ post-retirement public probe returned HTTP 200 from railiance01 with valid TLS.
 
 ```task
 id: RMASTER-WP-0020-T08
-status: todo
+status: wait
 priority: medium
 state_hub_task_id: "1dc50d98-64e8-4755-a52e-2b94b765019e"
 ```
@@ -261,6 +261,13 @@ Activity Core one-shot definition
 Europe/Berlin on 2026-08-17 by emitting a claimable ops run. The schedule never
 performs destructive cleanup itself.
 
+2026-08-14: Workplan moved from `backlog` to `blocked`. T08 is `wait`.
+The three gates are still closed: retention until 2026-08-17, a post-cutover
+railiance01 disaster-recovery drill (the 2026-08-03 isolated restore is T03,
+not this), and fresh explicit approval for destructive CoulombCore deletion.
+Do not reopen until those three are true. The 2026-08-17 one-shot may move
+the workplan to `active`; it still must not delete anything.
+
 ## Safety constraints
 
 - Never initialize or overwrite either OpenBao instance without verified