Stage A: fix USE's silent stack-underflow/bad-address guards, and the Hera fault-scoping gap they exposed (FABRIC-3.md §XXXII.1)

mama_word_use()'s two silent vm->error=1 guards (dsp<1 stack underflow,
NULL from vm_ptr()) now print a diagnostic and return, matching the
function's other five guards.

Live verification of that fix alone surfaced a bigger problem: with the
guard no longer silent, the REPL proceeds to interpret the leftover
token as an unrecognized word, which independently sets vm->error, and
sk_repl_step()/sk_repl_run()'s Hera-branch still hard-halted on that.
Investigated kernel_main.c's boot/capsule-load paths directly: they
already catch and clear mama->error entirely separately, before
sk_repl_run() is ever entered -- so the "no fallthrough surface" halt
in these two REPL functions was never protecting a boot-time fault, only
an ordinary interactive REPL-turn one. Both functions now recover
unconditionally on any VM's error, Hera included, matching how a
redirected (WIREBIND/USE'd) identity's session already recovered.
Removed the now-fully-unused sk_fault_handler().

Verified live, amd64: USE rajames at Zuse's own console prints the new
diagnostic, then "VM fault -- session recovered, resuming", console
stays interactive afterward. Three-arch clean qemu acceptance passed
before and after the Hera-fault-scoping change.

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

FABRIC-3.md

@@ -4213,6 +4213,39 @@ whichever fix lands, it must be verified by typing bare `USE <name>` at **Zuse's
 Hera). A WIREBIND identity's own guest session already recovers from this exact error today,
 pre-fix (§XI.4's fix already covers that path) -- testing there would be a false pass.
 
+**Stage A -- DONE, 2026-09-15, and escalated past option (a) once live testing forced the
+question.** Option (a) (both silent guards in `mama_word_use()` -- line 451's `dsp < 1` and
+line 467's `vm_ptr()` NULL check -- now print a diagnostic and `return;` without touching
+`vm->error`) landed first and was verified correct on its own terms. But the actual repro
+(`USE rajames` at Zuse's console) still halted the kernel afterward -- with the silent guard
+fixed, the REPL now proceeds to interpret the leftover `rajames` token as its own word,
+`vm_core.c:1106-1107`'s existing "unknown word" handling sets `vm->error = 1` exactly as
+designed, and `sk_repl_step()`'s Hera-branch halted on *that* error just as it would have on
+any other. This proved the original bug was never really about `USE`'s guard specifically --
+**any unrecognized word or ordinary interactive mistake typed at Zuse's own console hard-halted
+the entire kernel**, and always had, by the same mechanism.
+
+Brought back for a decision rather than fixed unilaterally, since it meant option (c) was
+actually required, not merely a bigger optional follow-on. Decided: narrow it now, same stage.
+Investigated first, not assumed: `kernel_main.c`'s boot/capsule-load call sites (the `--doe`
+injection at line 899-907, `SK_STARTUP_FORTH` at line 913-922) already catch and clear
+`mama->error` directly, entirely independent of `sk_repl_step()`/`sk_repl_run()` -- both of
+which are only ever reached once the interactive REPL loop is already running, well after boot.
+So the "no fallthrough surface" halt in those two functions was never actually protecting a
+boot-time fault; it could only ever fire on an ordinary interactive REPL-turn error, on any VM,
+Hera included. Fix (`repl.c`): both `sk_repl_step()`'s and `sk_repl_run()`'s error branches
+now recover unconditionally -- print "VM fault -- session recovered, resuming", clear
+`error`/`halted`/`abort_requested` -- with no special case for Hera's own direct session. The
+now-fully-unused `sk_fault_handler()` (and its "halts VM on error" doc-comment claim) were
+removed, matching this same file's own established precedent for retiring a function once its
+last caller is gone.
+
+**Verified live, amd64, the actual repro:** `USE rajames` at Zuse's own console now prints the
+new diagnostic, then "VM fault -- session recovered, resuming" for the resulting unknown-word
+error, and the console stays fully interactive afterward (`3 4 + .` correctly computed `7`
+immediately after). Three-architecture `clean qemu` acceptance (amd64/aarch64/riscv64) passed
+with the full fix, standard regression unaffected on all three.
+
 ### XXXII.2 -- Human vs. unattended identity/console-birth model
 
 **Current model, confirmed by reading `capsule_wirebind_try_attach()` end to end