Close §XXVIII: defer 2 known bugs to Stage 4 (FABRIC-3.md §XXIX)

Bob's call after an honest end-to-end status check: multitasking (fixed
Tripod fleet) and multiuser (Zuse/WIREBIND) each work for their own
tested paths, but two known bugs remain rather than zero -- the §XIV
concurrent WIREBIND attach detection gap, and the never-reconciled
MSG-TICK/Stage-3-switch dual-ownership rough edge. Both deliberately
deferred to be addressed during or at the close of Stage 4, since both
bear directly on WIREBIND VMs joining the switch-signal population.

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

FABRIC-3.md

@@ -3949,3 +3949,42 @@ three now reach `Startup: Artemis live` -> `[zuse@Hera] ok>` with **no** `VM-EXE
 at all -- confirming both that the fix is correct and that this was the sole cause of that
 report (nothing else was masking or contributing to it).
 
+## XXIX. Task closed, 2 known bugs explicitly deferred to Stage 4 (2026-09-14)
+
+**Bob's call, made after an honest end-to-end status check on both multitasking and multiuser:**
+both work, separately, for their own tested paths -- but "no known bugs" overstated it, and
+rather than chase either now, both are deliberately deferred, to be addressed as needed during
+or at the close of Stage 4 (WIREBIND-scope extension) rather than as a standalone detour first.
+Recorded here so Stage 4 opens with both already on its own punch list, not rediscovered.
+
+**Bug 1 -- §XIV, still open: concurrent WIREBIND attach detection gap.** Attaching several
+identity thumbdrives at (or near) the same real-time instant reliably causes the kernel to
+detect and birth only some of them; the rest never trigger `WIREBIND: <id> attached` at all.
+Confirmed not a QEMU-side issue (every device is genuinely present per host-level `query-block`)
+-- the gap is in the guest kernel's own per-tick attach-pending scan only surfacing one (or a
+few) of several simultaneously-pending port events. Sequential one-at-a-time attach (wait for
+each `WIREBIND: <id> attached` before the next) is the only confirmed-reliable path today.
+Directly relevant to Stage 4: extending preemption to WIREBIND VMs presumes those VMs exist and
+are attached reliably in the first place, including under the "already plugged in at power-on"
+case §XIV's own second reproduction showed failing.
+
+**Bug 2 -- the MSG-TICK/Stage-3-switch dual-ownership rough edge (§XXVIII's own admission,
+never revisited).** Both MSG-TICK's idle-pump dispatch and the Stage 3 timer-driven switcher can
+independently move control between the same VMs; not reconciled, not observed to interact badly
+so far, but never proven safe under all interleavings either. Directly relevant to Stage 4 for
+the same reason as Bug 1: WIREBIND VMs bring a second population of dynamically-birthed contexts
+into a switching story that already has one unreconciled ownership question among the fixed
+three.
+
+**Everything else closed out tonight (§XXVIII.2, §XXVIII.3) is verified clean on all 3
+architectures and not part of this deferral** -- the message-arrival eligibility hook, the
+trampoline-blind switch-storm fix, and the `SWITCH-MARK-WORK` off-by-one are done, done, done.
+
+**This closes the active §XXVIII thread in this document.** Preemptive multitasking works
+end-to-end for the fixed Tripod fleet (Hera/Hermes/Artemis); identity/multiuser (Zuse/WIREBIND)
+works end-to-end for its own tested paths; the two are not yet composed (Stage 4, not attempted);
+the two bugs above are the known, accepted, deferred debt against that composition. Bob has
+indicated a larger new initiative is coming that will be introduced during Stage 4 work itself
+-- not detailed here since it hasn't been scoped yet, flagged only so this closing note doesn't
+read as "nothing more is coming."
+