NK-WP-0054-T05: evidence — resolver password restored from custody; OpenBao login works

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 673304@bnt-lap001
Assistant-Session: 959b12c7-cf2e-440b-a60d-91229cc9e96e

docs/evidence/2026-10-30-nk54-bind-split/README.md

@@ -40,8 +40,13 @@ UTC, agent (Claude Code) guiding. All receipts are value-free (`values_recorded:
    every OTP check failed: KeyCape logged `mfa_failed` (`openbao-admin`) and `mfa_check_error`
    (`user-engine-portal`); privacyIDEA logged `LDAP Bind unsuccessful: invalidCredentials (49)` from
    19:00:10 UTC, last successful lookup 18:49:30 UTC, step 10 at 18:53 UTC. Founder found Bind DN
-   `uid=admin,…` on `lldap-coulomb` in the privacyIDEA UI, set `uid=svc-privacyidea,…` with the custody
-   `LLDAP_SVC_PRIVACYIDEA_PASS`, and **Test LDAP Resolver** passed. No repository tool rewrites the
+   `uid=admin,…` on `lldap-coulomb` in the privacyIDEA UI and changed it to `uid=svc-privacyidea,…`;
+   the Bind DN persisted but the hand-entered bind password did not match. A one-off attended script
+   (reusing `realm_bootstrap.py`'s client and custody reader) then wrote only `BINDPW` from the custody
+   `LLDAP_SVC_PRIVACYIDEA_PASS`, checked the other resolver fields unchanged and resolved
+   `platform-root` through the resolver; the founder's OpenBao OIDC login with OTP then succeeded.
+   Prefer the custody-fed write over UI entry: the German UI offered only the two test buttons, and
+   pasting the value by hand is error-prone. No repository tool rewrites the
    resolver, so step 8's apply most likely did not take effect; its OTP check passed only because the
    old shared password was still valid. Runbook step 8 now requires the resolver Bind DN and test, and
    step 10 a fresh OTP sign-in.