FABRIC-3.md §XI.4: record all 7 identities individually verified

00-06 each confirmed standalone (no Zuse): fast attach, USE, a
standard word computing correctly, and an ACL-denied VM-EXEC
recovering gracefully instead of halting -- exercising the fault-
scoping fix from the prior commit across every minted identity, not
just 00/01.

Also notes an out-of-scope hotplug finding: reusing an xHCI port for a
second identity right after an unclean (non-EJECT) detach of a first
wedges that port for further attaches. Worked around (fresh port/boot
per identity) rather than root-caused -- not part of this session's
task.

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

FABRIC-3.md

@@ -1900,3 +1900,18 @@ is preserved, only guest identity sessions are now scoped.
 timeout mid-boot (unrelated to this fix, no block-subsystem code touched this session; a clean
 retry booted normally, consistent with this project's known occasional QEMU/TCG flakiness, see
 `project_unexplained_qemu_sigterm_20260818.md`).
+
+With the halt-scoping fix confirmed, all 7 identities (`00`–`06`) were individually re-verified
+standalone (no Zuse, fresh boot per identity to sidestep an unrelated hotplug-recycling issue
+noted below): fast attach, `USE`, a standard word (`1 2 + .` / `9 9 * .`) computing correctly,
+and `VM-EXEC` (ACL-denied for this restricted personality) recovering gracefully — "VM-EXEC:
+ERROR in `NN~user`", console stays interactive, no halt — for every one of the 7.
+
+**Noted but out of scope, not investigated further:** attaching a second identity's drive to
+the same xHCI port within the same boot, immediately after an unclean (`device_del`, no `EJECT`
+word) detach of a first identity, reliably wedged that port — no further hotplug events reached
+the guest at all for any identity attached there afterward, console stuck on the dead first
+identity's own prompt. Working around it (fresh port per identity, or a fresh boot per identity)
+avoided it entirely and was sufficient for this verification pass; root cause (xHCI port-state
+settling, `g_wirebind_attached_*`/`g_repl_active_vm` single-active-binding assumptions colliding
+with a genuinely unclean detach, or both) is unexamined.