fix: contain attended login diagnostics and OpenBao recovery

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a137ca-5c77-7a71-b9ae-23ad9b0b5684

wiki/playbooks/openbao-platform-admin-login.md

@@ -89,3 +89,22 @@ messages; it should write only approved, value-free evidence to its own receipt.
 - Human identity and MFA provider: key-cape / Keycloak
 - Database-engine procedure owner: `rapp-postgres`
 - Routing decision and founder-act surface: WARDEN-WP-0029
+
+## 2026-10-15 contained failure diagnostics
+
+A failed login now reports only fixed categories (`callback_timeout`,
+`callback_error`, `authentication_error`, `unknown_client_failure`,
+`helper_persistence_missing`, `output_shape_rejected`), the numeric client exit
+code, helper-present and allowed-output booleans. These are observations, not
+authorization or proof of an issued session. The original captured bytes remain
+discarded, and the existing strict output allowlist is unchanged.
+
+Synthesized JSON-format flags precede positional auth data. OpenBao 2.5.5 also
+scans global format flags across argv; this normalization is not a proven fix
+for the October 15 timeout. Emergency self-revocation recognizes the estate's
+`s.` service-token shape as well as `hvs.`, `hvb.` and `hvr.`. Recovery still uses
+a value only in memory for `bao token revoke -self`, never a new handoff.
+
+The two CUST81 failed attempts remain failed and revocation-unconfirmed. Fresh
+Firefox profiles prove browser initialization, not callback completion. Source
+receipt: `docs/evidence/2026-10-15-cust81-attended-dependency-repair-r1.json`.