Prove the migration against live directories and fix what that surfaced

Finishes the unproven half of gap G04. Running the harness against real LLDAP,
OpenLDAP and Keycloak found four defects that the full unit suite passed over.

Every LLDAP user search pointed at a branch that does not exist. Config.userOU()
defaulted to ou=users while LLDAP stores users under ou=people, and nothing set
UserOU. LookupUser, ListUsers and ValidatePassword all derive from it, so all
three silently found nothing against a stock LLDAP -- human login included, not
only the export. Exposed by an export returning zero users while still emitting a
membership referencing uid=admin, a snapshot the repo's own validator rejects.

raw_attributes_well_formed, added one workplan earlier, rejected the LLDAP
adapter's own _validation_warning annotation, so the exporter's output failed its
own validation. Tooling annotations are exempt now, and a test proves the
exemption does not weaken the rule.

Migrated group memberships were dangling: resolveMemberDN passed a source DN
through unchanged while entries were written to the target branch, so groups
named entries the migrated directory does not contain. And empty groups could
not load at all, since groupOfNames makes member a MUST -- they reference a
placeholder entry the LDIF creates, an organizationalRole rather than a person,
emitted only when some group needs it.

The scenario-c compose file could not start: bitnami/openldap:2.6 does not
exist, though it passed docker compose config. Pinned to the image the scenario
was proved against.

Proof: LLDAP -> export -> validate -> LDIF -> ldapadd into OpenLDAP 1.5.0, every
entry added and every member resolving; a realm from the same export imports into
Keycloak and serves discovery. KeyCape passes 5/5 conformance checks, a migrated
Keycloak 4/5.

Relying-party behaviour and MFA against a migrated realm remain unexercised, and
credential/MFA migration is not supplied at all, so no harness can establish it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6

history/2026-09-05-011726-scope-intent-assessment.md

@@ -239,9 +239,41 @@ A migrated Keycloak therefore presents a wider grant surface than KeyCape does.
 This substantiates with evidence what SCOPE already said was unestablished, and
 means Scenario B legitimately reports a failure today rather than a green run.
 
-Still open: directory migration against a live OpenLDAP, credential and MFA
-preservation, and unchanged relying-party behaviour are not exercised. Scenario C
-has never been run end to end. G04 does not fully close.
+**Status 2026-09-08 (KEY-WP-0023): substantially closed.** Directory migration is
+now proved end to end into a real directory: LLDAP -> export -> validate -> LDIF
+-> ldapadd into OpenLDAP 1.5.0, every entry added without error and every member
+value in the loaded directory resolving to an entry that exists. The migrated
+Keycloak realm built from that same live export imported cleanly and served
+discovery, with the migrated user carrying keycape.canonicalId. Both sides of the
+swap are measured: KeyCape passes 5/5 conformance checks, a migrated Keycloak
+passes 4/5, failing only the excluded-grant check.
+
+Running it found four defects that the full unit suite passed over:
+
+1. `Config.userOU()` defaulted to `ou=users` while LLDAP stores users under
+   `ou=people`, and nothing set `UserOU`. LookupUser, ListUsers and
+   ValidatePassword all derive from it, so every user search against a stock
+   LLDAP silently found nothing — human login included. Exposed by an export that
+   returned zero users while emitting a membership referencing uid=admin.
+2. `raw_attributes_well_formed`, added in KEY-WP-0021, rejected the adapter's own
+   `_validation_warning` annotation, so the exporter's output failed its own
+   validation. Tooling annotations are now exempt and documented.
+3. LDIF members kept their source DNs while entries were written to the target
+   branch, so migrated groups referenced entries the target directory does not
+   contain.
+4. `groupOfNames` requires a member, so every empty group aborted the load. Empty
+   groups — preserved deliberately since KEY-WP-0018 — now reference a placeholder
+   entry the LDIF creates.
+
+A fifth was a harness defect: `bitnami/openldap:2.6` does not exist, so the
+compose file added in KEY-WP-0022 passed `docker compose config` and could not
+start. That is the distance between a file that parses and a stack that runs.
+
+Still open: no browser login was performed against the migrated realm, so
+unchanged relying-party behaviour is not established, and MFA was not exercised.
+Credential and MFA migration is a scope exclusion rather than a test gap — it is
+not supplied, so no harness can demonstrate it. Subject continuity is explicitly
+not preserved, which keycape-to-keycloak already reports.
 
 ### G05 — Directory export can omit data without reporting it