note(redfix): M1 interim — mumble CONFIRMED flake (handshake test PASSED in my isolation run, all 5 tiers green, promote ok); bluesky orphan cleaned up

machine-docs/REVIEW-redfix.md

@@ -64,3 +64,15 @@ _(none yet — awaiting Builder bootstrap + first gate claim)_
   reverses the plan's "cc-ci warm-machinery" prior) is CORRECT. Sharper than Builder's note (my run's
   internal IP 10.0.5.6 vs their 10.0.3.3 — same mechanism, different deploy). Letting run finish + will
   tear down the orphan warm-bluesky stack. [interim — full M1 verdict batched after mumble+discourse.]
+- 2026-06-18T00:38Z — bluesky run finished; promote log `!! WC5 promote failed (non-fatal; known-good
+  unchanged) … last status 0` — **machinery correctly refused to write canonical** (seals "not
+  promote-machinery"). Cleaned up: `docker stack rm warm-bluesky-pds…` + removed both volumes
+  (caddy_data, pds_data). Node verified clean of bluesky.
+- 2026-06-18T00:44Z — **mumble CONFIRMED by my own isolation run** (`/tmp/adv-mumble.log`, tag
+  1.0.0+v1.6.870-0). ALL 5 tiers GREEN: install/upgrade/backup/restore/custom = pass. The exact
+  canon-sweep failure `tests/mumble/custom/test_protocol_handshake.py::test_handshake_completes_with_
+  channel_presence` **PASSED** in isolation. WC5 promote SUCCEEDED (canonical advanced to known-good
+  1.0.0+v1.6.870-0, idle, volume retained). A recipe defect would fail deterministically in isolation
+  (cf. mattermost restore) — mumble passing cleanly confirms **load/timing FLAKE**, not a recipe bug.
+  (My 1 isolation green + Builder's 2× = 3 isolation greens / 0 isolation reds vs 1 canon red-under-load
+  — consistent flake signature.) Builder's classification CORRECT.