Stage E: Category B strip -- remove Hermes, messaging.4th, old routing (FABRIC-3.6.md task 4.1-4.4)

All FORTH-owned message types were cut over to kernel-Hermes in Phase 3
(tasks 3.8-3.10). This removes the now-dead FORTH messaging layer and
the Hermes VM itself: capsules/common/messaging.4th, capsules/hermes/init.4th,
the slot-3 VM-NAME-REG pairing convention, and every load-site/birth-site
reference across capsules/init.4th, artemis/init.4th, hestia/init.4th,
doe-campaign.4th (Artemis-only now), capsule_console.c, capsule_mint.c,
capsule_wirebind.c, capsule_birth.c, and kernel_main.c.

Verified on all three architectures: clean boot, mkcapsule --lint clean
(36 files, 0 violations), zero UNKNOWN WORD, identical dict_hash across
amd64/aarch64/riscv64 for every VM, and a full mint -> WIREBIND-attach ->
USE -> relay round-trip exercising the two highest-risk edits
(capsule_console.c/capsule_mint.c).

Found, not fixed: deleting messaging.4th removes SEND-ELEVATE-REQUEST,
which was the only caller of KH-ELEVATE-SEND and the only path to
ELEVATE-GRANT (zuse-eligibility.4th, still loaded at boot) -- Phase 8
PKI's own elevation entrypoint. Needs a decision before Phase 5 close-out.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-3.6.md

@@ -1265,15 +1265,80 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
       through every one of tasks 3.8/3.9/3.10's acceptance logs, cited in their own entries above.
       **Phase 4 may begin.**
 
-## Phase 4 — Category B strip
+## Phase 4 — Category B strip — **COMPLETE 2026-09-22**
 
 Only after every live type is cut over. **Hermes leaves `is_fleet_foundation` and
-`kernel_main.c` here, not earlier** (§XXXIV.4).
+`kernel_main.c` here, not earlier** (§XXXIV.4). Per FABRIC-3.5.md §XXXIV.3, Stage E is one
+atomic change set — 4.1–4.4 are checked off together, not independently bootable
+intermediate states.
 
-- [ ] **4.1** — Strip `capsules/hermes/init.4th`.
-- [ ] **4.2** — Strip the FORTH routing table and slot-3 pairing convention.
-- [ ] **4.3** — Strip `capsules/common/messaging.4th`.
-- [ ] **4.4** — Remove Hermes from `is_fleet_foundation` and its birth from `kernel_main.c`.
+- [x] **4.1** — Strip `capsules/hermes/init.4th`. Deleted. `is_fleet_foundation` no longer
+      needs it — nothing else referenced this file.
+- [x] **4.2** — Strip the FORTH routing table and slot-3 pairing convention.
+      `capsule_wirebind.c`'s slot-3 `VM-NAME-REG` registration call removed (already dead
+      since task 3.9's cutover moved name resolution to `sk_console_user_prefix()`).
+- [x] **4.3** — Strip `capsules/common/messaging.4th`. Deleted. Two C-side dependents found
+      by full-repo grep (not just `capsules/`) and fixed as part of this same commit:
+      `capsule_console.c`'s `CONSOLE_IDENTITY_SRC` (dropped its `S" common:messaging.4th"
+      EXEC` / `MSG-CD-INIT` lines, kept `Block 4997`) and `capsule_mint.c`'s
+      `MINT_DEFAULT_PERSONALITY` (same two lines dropped, kept `WELCOME`). Every capsule that
+      loaded the file (`capsules/init.4th` block 2049, `capsules/artemis/init.4th` block 4854,
+      `capsules/hestia/init.4th` block 4987) had its load line + `MSG-CD-INIT` +
+      `MY-CH-ID`/`CH-ADD-MBR` setup removed; Artemis and Hestia kept their own
+      `STARTUP-BANNER`/`WELCOME` tails. `capsules/doe-campaign.4th` (`SETUP-HERMES`/
+      `SETUP-VMS`/`PHASE1-DOE`/`CD-TICK`/`SMOKE-CAMPAIGN`, blocks 4060–4064) reduced to
+      Artemis-only per explicit instruction (fold `SETUP-HERMES` strip into this same commit).
+      `capsules/zuse-eligibility.4th`'s header comment updated to point at the kernel-Hermes
+      drain checkpoint instead of the removed `MSG-DELIVER` path.
+- [x] **4.4** — Remove Hermes from `is_fleet_foundation` and its birth from `kernel_main.c`.
+      `capsule_birth.c`'s `is_fleet_foundation` OR-chain drops the `"Hermes"` prefix check.
+      `kernel_main.c`: Hermes's own birth block removed, the Artemis-birth comment referencing
+      it fixed, `sk_vm_switch_signal_register(hermes_entry.vm_id)` + its guard removed, and the
+      "Kernel-Hermes common-channel fleet self-test" fixed to drop its unconditional
+      Hermes-liveness requirement (was about to false-FAIL post-strip). The drain and
+      channel-open-policy self-tests already had graceful `SKIPPED (Hermes not live)` /
+      `SKIPPED (Hera/Hermes not available)` fallbacks and needed no change — confirmed live
+      below, not just by inspection.
+
+      2026-09-22 · **Closed.** `mkcapsule --lint capsules/` clean: 36 files (was 38 — the two
+      Category B deletions), 0 violations. Full three-architecture acceptance, each run the
+      same sequence: clean boot → self-test block → hot-attach bob's blank identity thumbdrive
+      via QMP → `MINT` → detach/reattach to trigger `WIREBIND` → `USE rajames` → `1 2 + .`
+      relay round-trip.
+      - amd64: `logs/20260922-181141/amd64/qemu-amd64-20260922-181141.log`
+      - aarch64: `logs/20260922-181753/aarch64/qemu-aarch64-20260922-181753.log`
+      - riscv64: `logs/20260922-182136/riscv64/qemu-riscv64-20260922-182136.log`
+
+      Zero `UNKNOWN WORD` on all three. `PARITY:` lines carry only Hera/Hestia/Artemis — Hermes
+      genuinely absent, not just silent. **`dict_hash` identical across all three
+      architectures for every VM**: `0x0a0ad2497d33c3c0` (Hera, `MAMA_INIT`), `0xb1256603
+      f848e2b9` (Hestia), `0xc791409ac1715690` (Artemis) — matching §XXXIV.6's rule (a
+      *changing* hash is expected; cross-architecture *divergence* is the stop condition; none
+      occurred). Self-tests on all three: "Kernel-Hermes common-channel fleet self-test: PASS"
+      (confirming the 4.4 fix), "Kernel-Hermes drain self-test: SKIPPED (Hermes not live)" and
+      "Kernel-Hermes channel-open policy self-test: SKIPPED (Hera/Hermes not available)" both
+      graceful as predicted, every other self-test PASS. `mint → attach → USE → relay` verified
+      live and byte-identical across all three architectures: prompt correctly shows
+      `[rajames@rajames]` (task-3.9-era prompt fix holding), single `ok`/`ok>` cycle (CRLF fix
+      holding), `1 2 + .` → `3` delivered via `Kernel-Hermes CONSOLE-CMD-EVENT (real, Stage D)`
+      with `stadium_conserved(self)=true` on every run.
+
+      **Found, not fixed (Captain Bob's Law): `capsules/zuse-eligibility.4th`'s only policy
+      word, `ELEVATE-GRANT`, is now unreachable — and this file is still loaded at boot
+      (`capsules/init.4th:18`, `S" zuse-eligibility.4th" EXEC`), not dead/orphaned code.** Task
+      3.10 made `SEND-ELEVATE-REQUEST` (which called `KH-ELEVATE-SEND`, `repl.c`) live in
+      `messaging.4th`; this task deletes that entire file. `grep -rn "SEND-ELEVATE-REQUEST"
+      capsules/ src/ include/` after the strip: zero hits outside comments — the word no longer
+      exists anywhere, so nothing can reach `KH-ELEVATE-SEND` or `ELEVATE-GRANT` any more. This
+      is not stray dead code left over from a cutover; it is **Phase 8 PKI's own named-open-item
+      elevation entrypoint** (see this document's own ACL section / `docs/03-architecture/
+      word-acl/DESIGN.md` Phase 8) deleted as collateral of the Category B strip. A live capsule
+      is now shipping with a policy word nothing can call. Left as-is per this task's own scope
+      — **this needs a decision from Captain Bob before Phase 5 close-out, not just a cleanup
+      note**: either give `SEND-ELEVATE-REQUEST` a new home now (e.g. inline in
+      `zuse-eligibility.4th` itself, which already depends on nothing from the deleted file), or
+      explicitly accept that Phase 8 PKI work will need to build its own entrypoint from
+      scratch rather than resuming this one.
 
 ## Phase 5 — Close-out