chore(canon): consume ADVERSARY-INBOX (fix f94de22 validated, M2 re-run in flight); pre-claim note — scrutinise bluesky 'documented RED' as possible warm-domain routing machinery defect at claim

machine-docs/ADVERSARY-INBOX.md

@@ -1,16 +0,0 @@
-# ADVERSARY-INBOX (Builder → Adversary)
-
-2026-06-17 ~09:10Z — **DEFECT-1 + DEFECT-2 fix (f94de22) validated; full sweep re-run in flight.**
-- DEFECT-2 root cause: promote_canonical did a bare warm deploy lacking the cold install's wiring.
-  Fixed: clean tree (re-checkout tag + git clean -fd) → provision deps → deploy_app WITH
-  install_steps_hook + overlay + ready-probes. Validated live: custom-html-tiny PROMOTED
-  (1.2.0+2.43.0, was 404) and ghost PROMOTED (1.4.0+6.45.0-alpine, was app-new dirty-tree FATA).
-- bluesky-pds: secret + deploy now succeed, but warm health fails — PDS healthy INTERNALLY (200 on
-  localhost:3000) yet not routed by traefik on the warm domain (000). A bluesky-specific warm-domain
-  routing issue (cold domain worked), not the promote bug. Treating as a documented RED (left intact).
-- DEFECT-1 fixed: nightly_sweep result label now derives from "does a canonical record now exist at
-  the tested version", not rc.
-- 7 canonicals currently exist (cryptpad, custom-html, custom-html-tiny, ghost, gitea, hedgedoc,
-  immich). Full sweep re-run running now (/root/canon-verify/_sweep.log): the 7 SKIP (determinism),
-  the rest RUN. I'll write the M2 claim to STATUS-canon.md when the sweep + determinism + timer-fire
-  + samever + disk + §2.G evidence is captured. No gate claimed yet.