std79 DoE campaign rerun post-Stage-4: 81/81, §XIV caught live by rerun's own harness bug (FABRIC-3.md §XXXI)

Reran the established 3x9x3 randomized full-factorial campaign
(std79-doe.fth) on all 3 architectures per standing project discipline
(any Stadium-adjacent change reruns the whole DoE from the top).

First amd64 attempt exposed a real test-harness bug that re-triggered
the already-known §XIV concurrent-attach gap: the sequential-attach wait
loop checked for any recent WIREBIND-attached line instead of the
specific identity requested, firing the next device_add before the
kernel finished the current one. Only 2 of 8 identities attached; the
campaign itself completed cleanly with graceful "VM-EXEC: VM not found"
refusals rather than corrupting anything. Fixed the wait loop, discarded
the invalid run's campaign result (its boot log kept for the record),
reran clean.

Corrected reruns: all 8 identities individually confirmed on all 3
architectures, zero VM-not-found errors, zero faults, 81/81 trials
correct against established baseline values. Raw logs archived at
experiments/std79-doe/results-20260915-stage4/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K

experiments/std79-doe/README.md

@@ -95,3 +95,21 @@ sd(K) = 0, 100% conserved, across all three architectures, nine identities, and
 replicates — zero deviation.** See `report-20260912/README.md` for the full pipeline and the
 report itself for the complete analysis and discussion, including why this also serves as a
 free regression check on the two Stadium fixes (§XVI–XVII) that landed the same week.
+
+`results-20260915-stage4/` — rerun after FABRIC-3.md §XXVIII Stage 4 (WIREBIND VMs as Stage 3
+switch-signal participants + mark-and-defer tombstone reap), same discipline as every prior
+Stadium-adjacent change: any relevant mechanism change reruns the whole DoE from the top, one
+boot per architecture, all 9 identities simultaneously live, same seed (12345). **Result: 81/81
+trials correct, 0 mismatches, 0 `VM-EXEC: VM not found` errors, zero `VM fault` halts, on all
+three architectures.** Note for anyone rerunning this: the sequential-attach wait loop must
+confirm each identity's own specific `WIREBIND: <name> attached and ready` line before
+proceeding to the next — a loop that just checks for *any* recent WIREBIND-attached line will
+spuriously "succeed" immediately and fire the next `device_add` before the kernel has actually
+finished the current one, re-triggering §XIV's own known concurrent-attach detection gap (caught
+live during this rerun: a first attempt with a buggy wait loop attached only 2 of 8 identities,
+though the campaign itself still completed cleanly with graceful `VM-EXEC: VM not found`
+refusals for the missing ones rather than corrupting anything — the harness bug, not a kernel
+defect). This campaign still drives every identity via direct `VM-EXEC` dispatch, same as every
+prior run — it does not itself exercise Stage 4's new switch-signal participation, which was
+verified separately (see FABRIC-3.md §XXX for the live multiuser-attach + preemption-fleet
+verification that does).