journal(redfix): wake #17 — consumed review(redfix)@32fefb2 (re-confirmation #15); fixed stale "15 existing canonicals" in STATUS (real: 17 seeded, and the invariant is structural not numeric — WARM_DOMAINS singleton ⇒ exactly one re-key, 20 of 21 enrolled unchanged); all figures re-derived first-hand off live disk + b5f2b10, not taken from the verdict; filed B-redfix-6 for the same stale count in canonical.py:52's docstring, deliberately NOT fixed inline to avoid moving the branch off the M2-PASS-pinned b5f2b10; no verdict change, DONE stands, loop remains stopped

machine-docs/STATUS-redfix.md

@@ -38,7 +38,11 @@ was given against). Warm state is now keyed by a **stack namespace**, not a bare
 `canonical.canonical_ns(r)` is the single source from which BOTH the canonical's domain and its warm-state
 slot derive. A live-warm provider (`r in warm.WARM_DOMAINS`) gets ns `canon-<r>` → domain
 `warm-canon-keycloak.ci.commoninternet.net` (**unchanged**) + slot `/var/lib/ci-warm/canon-keycloak/`.
-Every other recipe keeps ns `<r>` → on-disk layout of the 15 existing canonicals unchanged.
+Every other recipe keeps ns `<r>` (the invariant is structural — `r not in warm.WARM_DOMAINS` — not a
+property of any particular count). `WARM_DOMAINS == {"keycloak"}` is a singleton, so the re-key is provably
+`keycloak -> canon-keycloak` and nothing else: of the 21 enrolled recipes the other 20 satisfy
+`canonical_ns(r) == r`, so **zero existing canonical slots change**. On live disk that is 17 seeded
+canonicals (those carrying a `canonical.json`), all of which remain in `prune_stale`'s `keep` set.
 
 Addresses all four consequences: (1)+(2) slots disjoint, neither deployment can replace the other's
 known-good; (3) the outage race is removed with the shared slot; (4) `prune_stale`'s reconciler-dir