Scope VM fault halt to the faulting identity's own session (FABRIC-3.md §XI.4)

A standalone WIREBIND identity (no Zuse, USE'd in directly) hitting an
ACL-denied word halted the entire machine -- Hera, Hermes, Artemis, all
of it -- instead of just that identity's own session. sk_fault_handler()
was being called unconditionally on whichever VM's ->error was set, with
no distinction between Hera's own root session (where "no fallthrough
surface" is the correct, deliberate fail-closed behavior) and a
USE'd-in guest identity (which should recover and resume at its own
prompt instead of taking the fleet down with it).

Both call sites (sk_repl_step, sk_repl_run) now compare the faulting VM
against Hera before deciding: Hera's own session still halts by design;
any other VM prints a recovery message, clears its fault state, and
continues.

Also: mint identities 01-06 with the same FORTH-79/83 restricted
personality identity 00 already had, verified via the fixed fault
scoping above (which this verification pass surfaced).

Verified live on amd64 (both the Hera-halts and identity-recovers
branches); three-arch clean qemu acceptance passed (riscv64's first
attempt hit an unrelated virtio_blk I/O timeout hang, a known QEMU/TCG
flake -- a clean retry booted normally).

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

FABRIC-3.md

@@ -1852,3 +1852,51 @@ just of her ever attaching at all before this point). Both bugs happened to corr
 "Zuse first" framing without being caused by it — a genuine trap for exactly the kind of
 live-forensics-driven investigation this section is a record of, and worth naming plainly
 rather than editing out of the historical record.
+
+### XI.4 — Identities 01–06 minted with the restricted personality; a standalone identity's
+ACL denial halted the whole machine, not just that session — CLOSED
+
+With §XI.3 fixed, all 6 remaining identity thumbdrives (`01`–`06`) were re-minted with the same
+`MINT_PERSONALITY_STD79_LOCKDOWN` restricted personality identity `00` already had (§IX/`f4ded3e`):
+each drive's devblock-1 signature was zeroed (`dd ... seek=1 count=1 conv=notrunc`, invalidating
+recognition without touching the rest of the drive) and re-minted via `-1 MINT` in a single
+Zuse-attached boot. All 6 confirmed via "MINT: identity minted".
+
+Verifying identity `00` standalone (no Zuse, `USE`'d in, typing `VM-EXEC` to confirm a denied
+word is refused without taking anything else down) surfaced a real bug: the denial *did* refuse
+correctly, but the entire machine halted — Hera, Hermes, Artemis, everything — not just that
+one identity's own session. Root cause: `sk_fault_handler()` (`repl.c`, gated by
+`EMERGENCY_CONSOLE_ENABLED=0`, the production default) is genuinely correct, deliberate,
+fail-closed behavior for **Hera's own** session — "no fallthrough surface" is exactly the right
+call when the primary console itself faults. But both of its call sites (`sk_repl_step()`,
+`sk_repl_run()`'s main loop) called it unconditionally on whichever VM's `->error` was set,
+with no distinction between "this is Hera's own bare session faulting" and "this is a guest
+identity's `USE`'d-in session faulting" — so a WIREBIND identity's ACL denial halted Hera right
+along with itself, an ordinary FORTH-79 command mistake for a non-privileged guest taking down
+the whole fleet.
+
+Fix (`repl.c`, both call sites): compare the faulting VM against Hera specifically before
+deciding — `sk_repl_step()` already had the right comparison available
+(`vm == (VM *)sk_get_mama_vm()`); `sk_repl_run()`'s loop needed the same, using its own `active`
+(the `USE`-redirected VM, defaulting to `vm`/Hera when nothing is redirected — see
+`g_repl_active_vm`). Hera's own session still calls `sk_fault_handler()` (halts, by design) when
+the comparison matches; any other VM instead prints "VM fault -- session recovered, resuming",
+clears `->error`/`->halted`/`->abort_requested`, and lets the REPL loop continue — the session
+recovers at its own next prompt instead of taking the machine down with it.
+
+Live-debugging note: the first attempt to verify this fix (before this session's own
+compaction) appeared to fail — the old halt message still fired. Root cause of *that*: a leaked
+`qemu-system-x86_64` process from the same investigation, still running the *pre-fix* binary,
+was mistaken for a fresh boot (see `feedback_check_leaked_qemu_procs_before_slow_theory.md`).
+Once that stale process was killed and a genuinely fresh instance booted, both cases verified
+correctly on the first try: an identity's own `USE`'d session recovers gracefully from a denied
+`VM-EXEC` (console stayed fully interactive afterward, confirmed with a follow-up arithmetic
+command), and Hera's own bare `zuse)ok>` session still halts correctly on a genuine fault
+(confirmed with a deliberately-undefined word) — the fail-closed intent for the primary console
+is preserved, only guest identity sessions are now scoped.
+
+**Verified:** live on amd64 (both branches, as above); three-arch `clean qemu` acceptance
+(amd64/aarch64/riscv64) all passed — riscv64's first attempt hung with a `virtio_blk` I/O
+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`).