review(m2-redfix): M2 PASS — VETO CLEARED, F-redfix-4 CLOSED (remedy verified cold at b5f2b10)

Cold-verified redfix-m2-harness@b5f2b10 (parent 07fc6d4 = the sha the earlier M2 PASS was
given against, so the other five fixes are provably untouched by this commit).

Clearing condition MET verbatim: live_slot=keycloak vs canonical_slot=canon-keycloak are
disjoint; restore(canon) and restore(live) each return their OWN stack's volumes; reconciler
last_good survives; foreign snapshot AND foreign restore both refused (probed both directions).
canonical_domain unchanged, so M2's original keycloak evidence still stands.

Checks the Builder did not run:
 - integrity: canon mariadb byte-identical across the destructive restore round-trip
   (cksum 4271926745 166164480, 386 files, before and after).
 - mutation testing (are the +10 tests vacuous?): reverting canonical_ns() to `return recipe`
   reds 4 of them; removing both _assert_slot_not_foreign() call sites reds 2. Not vacuous.
   Suites reproduce exactly: 325 passed @b5f2b10, 315 passed @07fc6d4.
 - caller audit: every snapshot/restore/app_dir/snap_dir call site passes an explicit slot;
   no bare recipe survives.
 - blast radius (the risk this refactor most plausibly created): all 21 enrolled recipes still
   resolve to their EXISTING on-disk dirs; registry_path("bluesky-pds") is character-identical
   at parent and fix. The 3 without a registry have no dir at all and never did. No migration.
 - prune_stale invariant now structural: <recipe>/ never gains a canonical.json, so a
   de-enrolled provider can no longer rmtree the reconciler's last_good (scratch-root sim,
   fake ns only — prune_stale calls `docker volume rm`).

Enrollment retained (WARM_CANONICAL=True), no silent de-enrollment. Both false
"can never touch each other" comments removed.

B-redfix-5 (reconciler rollback restore() outside the upgrade try/except) accepted as
NON-BLOCKING: verified verbatim present at parent 07fc6d4, so it predates the enrollment.
F-redfix-4 made it reachable; that path is now closed. Correctly filed, not silently fixed.

All six recipes now hold a fresh Adversary PASS; F-redfix-1/2/3/4 CLOSED; no open blocking
finding. Builder may re-assert ## DONE.

Node clean: throwaway volume + scratch removed, real warm root untouched (keycloak/ = last_good
only, no canon-keycloak/ created), canon volumes intact, live keycloak /realms/master 200 throughout.

machine-docs/BACKLOG-redfix.md

@@ -74,7 +74,34 @@ hold). Concrete fix designs from M1 evidence:
 
 (Adversary-owned — do not edit.)
 
-### [adversary] F-redfix-4 — keycloak enrollment is collision-free in DOMAIN but NOT in warm-state: the live-warm reconciler and the new data-warm canonical share one per-recipe snapshot slot — **OPEN, BLOCKING (VETO)** @2026-07-08T23:56Z
+### [adversary] F-redfix-4 — keycloak enrollment is collision-free in DOMAIN but NOT in warm-state: the live-warm reconciler and the new data-warm canonical share one per-recipe snapshot slot — **CLOSED @2026-07-09T00:18Z (VETO CLEARED)**
+
+**CLOSED by Adversary re-test.** Fixed at `redfix-m2-harness`@`b5f2b10` (parent `07fc6d4`): `canonical_ns()`
+is now the single namespace behind BOTH the canonical's domain and its warm-state slot, so a live-warm
+provider gets slot `canon-<recipe>/`, disjoint from the reconciler's `<recipe>/`. Plus a
+naming-independent `_assert_slot_not_foreign()` guard on snapshot AND restore.
+
+My cold re-test (full evidence in REVIEW-redfix.md @2026-07-09T00:18Z): the published clearing condition is
+met verbatim — slots disjoint, `restore(canon)` and `restore(live)` each return their OWN stack's volumes,
+reconciler `last_good` survives, foreign snapshot *and* foreign restore both refused. Beyond the Builder's
+own checks I added four: (a) the canon mariadb volume is byte-identical across the destructive restore
+round-trip (`4271926745 166164480`, 386 files); (b) **mutation testing** — reverting `canonical_ns()` reds 4
+of the new tests, removing the guard reds 2, so the 315→325 test delta is not vacuous; (c) every
+`snapshot`/`restore`/`app_dir` caller now passes an explicit slot, no bare recipe survives; (d) all 21
+enrolled recipes still resolve to their existing on-disk dirs (`registry_path("bluesky-pds")` is
+character-identical at parent and fix) — zero blast radius, no migration needed.
+
+Consequences 1–3 resolved. Consequence 4 (`prune_stale`) is now structural: `<recipe>/` never gains a
+`canonical.json`, verified in a scratch root. Enrollment retained (`WARM_CANONICAL = True`) — no silent
+de-enrollment. The two false "can never touch each other" comments are gone.
+
+Residual **B-redfix-5** (reconciler rollback `restore()` outside the upgrade's `try/except`) is NOT part of
+this finding's clearing condition and is **not** blocking: I confirmed it is verbatim present at parent
+`07fc6d4`, so it predates the enrollment. F-redfix-4 made it *reachable*; that path is now closed.
+
+<details><summary>Original report (as filed 2026-07-08T23:56Z)</summary>
+
+### [adversary] F-redfix-4 — original text — **OPEN, BLOCKING (VETO)**
 
 **Severity:** BLOCKS the phase's keycloak DoD item and must be fixed before the operator merges
 `redfix-m2-harness`. Worst case is an outage of the live shared OIDC provider that `lasuite-*`/`drone`
@@ -173,6 +200,8 @@ de-enroll keycloak and re-open the DoD item, so it is not sufficient.
 survives a live-reconciler stateful upgrade (and vice versa) — demonstrated by re-running the repro above and
 seeing each `restore()` return its OWN stack's volumes.
 
+</details>
+
 ---
 
 ### [adversary] F-redfix-1 — discourse migration INCOMPLETE: dangling image-less `sidekiq` in compose.smtpauth.yml (R011 lint regression + breaks SMTP-auth deploys) — **CLOSED @2026-06-18T07:06Z**