Reconcile identity state onto railiance01

docs/railiance01-coulombcore-cutover-inventory-2026-07-28.md

@@ -117,14 +117,59 @@ instance UUID) differs. Migrating only database rows would make the enrolled
 token unusable. The CoulombCore privacyIDEA database plus its encryption and
 signing custody must move as one rollback-tested unit.
 
+## Persistent-state reconciliation
+
+T03 used a bounded write freeze covering KeyCape, LLDAP, privacyIDEA, and
+user-engine where present. Fresh encrypted frozen snapshots were created at:
+
+- CoulombCore:
+  `~/identity-cutover-backups/2026-07-28T0925Z-pre-migration-source`;
+- railiance01:
+  `~/identity-cutover-backups/2026-07-28T0925Z-pre-migration-destination`.
+
+Both sets contain LLDAP, privacyIDEA database and custody, and interhub
+rollback artifacts with passing relative-path checksum manifests.
+
+LLDAP was reconciled as a selective union. The CoulombCore `platform-root`
+row, attributes, and memberships are authoritative. railiance01's bootstrap
+admin, destination test user, and Binky tenant groups remain authoritative.
+Shared groups were mapped by normalized group name, and the source-only
+`whynot-design` and `activity-core-operators` groups were added with
+collision-free destination IDs. The known `--cleanup-only` and
+`t06-final-*` lifecycle-test identities were deliberately excluded.
+
+Post-restart LLDAP evidence is:
+
+- SQLite integrity: `ok`;
+- users/groups/memberships: `3/9/6`;
+- `platform-root` memberships: `4`;
+- destination test user preserved: `1`;
+- excluded source test artifacts present: `0`.
+
+The complete CoulombCore privacyIDEA database and its matching encryption
+key, audit signing keypair, and instance UUID were applied as one unit.
+All four custody fingerprints match the source. Source and destination now
+both report one token, one token owner, two realms, two resolvers, and two
+policies. privacyIDEA returned HTTP 200 after restart.
+
+CoulombCore interhub data was loaded into railiance01's newer schema rather
+than replacing that schema. A legacy `hubs.hub_family` column was intentionally
+discarded after the first data-only restore rejected the mismatch and the
+encrypted destination snapshot was restored. All twelve nonempty source-table
+row counts and stable row digests match, including a common-column digest for
+`hubs`. railiance01's 16-row migration ledger and one destination-only user
+were preserved.
+
+Temporary helper pods, shared-memory databases, dumps, archives, and restore
+logs were removed. CoulombCore identity writers remain scaled to zero to
+prevent divergence while the railiance01 direct-resolution conformance gates
+run; no PVC, Secret, database, or workload declaration was deleted.
+
 ## Required next evidence
 
-1. Copy the encrypted backup set to independent custody and perform an
-   isolated PostgreSQL/privacyIDEA restore drill.
-2. Decide the LLDAP merge rule for the one source-only user and four
-   source-only memberships while preserving railiance01-only lifecycle groups.
-3. Freeze writes, migrate privacyIDEA database and custody as one unit, and
-   migrate/merge authoritative LLDAP state.
-4. Rerun semantic counts/digests and restart recovery probes.
-5. Exercise platform-root and Binky login/MFA.
-6. Move LLDAP and privacyIDEA DNS only after those gates pass.
+1. Reconcile cluster-local configuration and prove that railiance01 has no
+   runtime dependency on CoulombCore.
+2. Exercise platform-root and Binky login/MFA using TLS-preserving direct
+   resolution to railiance01.
+3. Verify KeyCape service-client flows and negative authorization probes.
+4. Move LLDAP and privacyIDEA DNS only after those gates pass.