Close NK-WP-0034: verify-t06 proven FAIL-then-PASS on production

Production lldap-coulomb lacked TIMEOUT/CACHE_TIMEOUT/SIZELIMIT since the
2026-08-27 unrepaired apply; the new verifier failed at resolver-tuning,
the repaired attended --apply restored them (DB readback confirmed), and
verify-t06 now passes all four proofs.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e

workplans/NK-WP-0033-keycape-secret-exposure-rotation.md

@@ -265,3 +265,7 @@ The 2026-09-11 identity-provisioner repair confirmed
 
 Predecessor disposition follows the operator ruling above. T03 and T05 are
 done, and the incident `KEYCAPE-EXPOSURE-20260823-01` is closed.
+
+Follow-up the same day: the repaired `--apply` restored the resolver tuning
+fields that the 2026-08-27 run had dropped. The receipt passed; see NK-WP-0034
+for the details.

workplans/NK-WP-0034-verification-that-verifies.md

@@ -4,12 +4,12 @@ type: workplan
 title: "Make the SSO/MFA verification actually verify"
 domain: infotech
 repo: net-kingdom
-status: blocked
+status: finished
 flavor: implementation
 owner: codex
 topic_slug: infotech
 created: "2026-08-28"
-updated: "2026-09-05"
+updated: "2026-09-23"
 related:
   - NK-WP-0033
   - CUST-ADR-012
@@ -47,7 +47,7 @@ is broken, which is worse than no check, because it is believed.
 
 ```task
 id: NK-WP-0034-T01
-status: wait
+status: done
 priority: high
 state_hub_task_id: "9b5d8034-0ef1-53f9-ad4d-37de536bdc62"
 ```
@@ -163,3 +163,38 @@ State Hub reconciliation was attempted with both the installed CLI and current
 checkout. Full reconciliation remains pending because API queries/writes timed
 out or returned connection-refused errors. Generated index/intake metadata was
 reviewed; the source files remain authoritative.
+
+## Attended acceptance — 2026-09-23 (T01 done)
+
+T01's acceptance was demonstrated in both directions on production
+privacyIDEA. The fields were **not** cleared on purpose: production had been
+missing them since 2026-08-27. The operator was Bernd Worsch, using railiance01
+checkout `6096c395`.
+
+1. **FAIL, fields absent.** `verify-t06.sh --user platform-root` failed twice
+   (runs at 18:41:54 and 18:42:22 server time). The privacyIDEA audit shows
+   pi-admin auth, `GET /realm/` and `GET /resolver/lldap-coulomb` succeeding,
+   and no user lookup after them. That places the failure in the
+   `resolver-tuning` phase. The live `lldap-coulomb` config had 11 keys and
+   no `TIMEOUT`, `CACHE_TIMEOUT` or `SIZELIMIT`. The unrepaired
+   `reconcile-lldap-resolver-live.sh --apply` of 2026-08-27 (NK-WP-0033
+   defect 3) had dropped them, and the old T06 passed regardless.
+2. **Restore.** With operator approval, the repaired
+   `reconcile-lldap-resolver-live.sh --apply --predecessor-unavailable` ran at
+   19:14:45 and made one resolver write. Before the write, every non-secret
+   value was confirmed identical to the declared body, and the bind value came
+   from `operators/lldap/admin` version 1. Receipt: `PASS: resolver lookup,
+   privacyIDEA MFA, predecessor denial=NOT-PROVEN, readiness, health,
+   cleanup=PASS`. A database readback shows `TIMEOUT=5`, `CACHE_TIMEOUT=120`
+   and `SIZELIMIT=500`, 14 keys in total.
+3. **PASS, fields restored.** `verify-t06.sh --user platform-root` returned
+   `{"phase": "complete", "proofs": ["realm-binding", "resolver-tuning",
+   "known-user-lookup", "token-backed-mfa"], "result": "PASS"}`.
+
+The scratch-target exercise planned earlier in the session is no longer
+needed. The failure direction was observed on the real target, attributed
+through the audit log, and reversed by the declared remediation.
+
+Two runs in the same session failed at `authentication` because the wrong
+pi-admin value was entered (audit: "Wrong credentials"). Neither was a
+defect in the verifier.