fix: route OpenBao recovery ceremonies safely

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0290b-3241-74c3-b868-6049545af836

registry/routing/catalog.yaml

@@ -171,6 +171,29 @@ entries:
     exec_capable: true
     lane: login
 
+  - id: openbao-shamir-recovery-ceremony
+    title: Attended OpenBao Shamir seal and unseal recovery ceremony
+    # A ceremony pointer, not a credential-value lane. Approval coordinates
+    # existing out-of-band custodians; Warden never requests or transports a share.
+    risk: high
+    workload_ref:
+      applicability: not-applicable
+      reason: "Attended platform trust-root ceremony; no workload credential is retrieved."
+    need_keywords: [openbao, shamir, seal, unseal, sealed, emergency, recovery, break-glass, quorum, share, shares, custodian, ceremony, raft, snapshot, provider-console, abort, attended]
+    owner_repo: railiance-platform
+    subsystem: OpenBao operator recovery
+    warden_executes: false
+    wiki_ref: wiki/playbooks/openbao-shamir-recovery-ceremony.md#worker-checklist
+    canon_ref: railiance-platform/docs/railiance01-coordinated-reboot.md
+    reviewed: "2026-08-22"
+    status: active
+    delegation:
+      mode: native
+      intended_owner: railiance-platform
+      reviewed: "2026-08-22"
+      verified: source-read
+    lane: ceremony
+
   - id: whynot-design-npm-publish
     title: whynot-design npm publish token (@whynot/design → coulomb Gitea registry)
     # Publish rights to the package registry — a leaked token is a supply-chain write, not a read (WARDEN-WP-0032-T05).