NK-WP-0049-T18: original OpenBao restored in isolation (RPF-WP-0064); consumer login run remains

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4384@bnt-lap001
Assistant-Session: 80d1f3da-7a91-4519-9737-9ba128b4da64

workplans/NK-WP-0049-bootstrap-secret-free-recovery-handoff.md

@@ -631,6 +631,14 @@ The receipt itself is not in Git: the local and Forgejo secret scanners flag its
 (`generic-api-key`, file names containing "keycape"), and the founder chose not to re-encode or exempt it. The exact
 original is retained outside Git on the founder workstation (mode 0400), bound by sha256 `16d72f7c…1651` in the
 verifier output. This deviates from the ceremony step 5 retention path by founder decision 2026-10-23.
+
+2026-10-24: the OpenBao dependency for this consumer is recovered at configuration level. railiance-platform
+RPF-WP-0064-T07 restored the original OpenBao from the 2026-10-14 off-host snapshot into a networkless target,
+founder attended (attempt `-03`, adapter `7084b57`), verified independently (receipt `sha256:4e048dee…579d`,
+outside Git): original cluster id, the `secrets-engine-openbao` JWT role, its policy and KV metadata all match
+source. T18 consumer acceptance still needs the live login run: RPF-WP-0064 phase B (internal network joining
+the isolated NK49 KeyCape and restored OpenBao) plus the SECRETS-WP-0015-T04 consumer run, each separately
+founder-admitted. MFA remains T19.
 Still open for T18: selected current consumer acceptance against restored dependencies (the receipt claims
 no consumer continuity), and owner acceptance; MFA stays T19.