Stage D: ELEVATE-REQUEST real cutover -- FABRIC-3.6.md task 3.10

Reachability verified live before writing any code, per this
project's own standing rule (grep cannot establish reachability
alone): FIND SEND-ELEVATE-REQUEST / FIND ELEVATE-GRANT / FIND
CH-REQUEST all resolve on a live Hera boot, though grep across
capsules/experiments/docs found zero callers of SEND-ELEVATE-REQUEST
-- a real, complete, directly-callable entrypoint (H.5/H.8's own
design) with no current automatic trigger, not dead code.

Correction to a prior finding, made in the course of this check: task
3.8's write-up claimed "Hera's own pre-existing inability to load
common:messaging.4th" -- false. capsules/init.4th (Hera's own
MAMA_INIT capsule) loads it directly, and SEND-ELEVATE-REQUEST lives
and works in her dictionary right now. Task 3.8's own actual scope is
unaffected by this correction.

Cutover: SEND-ELEVATE-REQUEST (messaging.4th) no longer ends in
CH-REQUEST's COMMON-CH/MSG-SEND path; it now calls KH-ELEVATE-SEND
(repl.c), a new C word wrapping sk_hermes_send_one(), registered
unconditionally for every VM. from/to are derived from the calling VM
and sk_get_mama_vm() directly in C, never taken from the stack -- a
real correctness improvement over CH-REQUEST's own initiator-only
gate, which only existed because a caller COULD pass the wrong from
value; deriving it in C makes that spoof structurally impossible.
SK_HERMES_MSG_TYPE_ELEVATE_REQUEST reuses ELEVATE-REQUEST's own value
(8), same partition-rule reasoning as tasks 3.8/3.9. Delivery is
unchanged task 3.4 machinery. No new static-buffer lifetime caveat --
the payload-aliasing fix landed before this task started.

CH-REQUEST (messaging.4th) is now dead code, its one real caller just
removed -- found, not fixed, per Captain Bob's Law.

Verified live on all three architectures: 0 0 0 0 S" DUP"
SEND-ELEVATE-REQUEST (deliberately-invalid pubkey, so ELEVATE-GRANT
correctly refuses -- the check is the pipeline running, not a grant
succeeding) fires the evidence line and completes cleanly, DUP
unaffected afterward. Zero UNKNOWN WORD, dict_hash identical across
all three architectures (changed uniformly from prior runs -- one new
word registered -- not diverged, matching SXXXIV.6's own rule).

This closes task 3.11 (Phase 3 gate): all of messaging.4th's live
FORTH-owned message types (BLK-ATTACH-EVENT, CONSOLE-CMD-EVENT,
ELEVATE-REQUEST) are now real kernel-Hermes cutovers. Phase 4 may
begin.

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

FABRIC-3.6.md

@@ -732,14 +732,15 @@ Hestia; headless policy intact.
 
       **Phase 2 is complete (2.1–2.8).** Phase 3 remains blocked on B1, B2, B4.
 
-## Phase 3 — Cutover — **UNBLOCKED, tasks not yet written**
+## Phase 3 — Cutover — **COMPLETE, gate (3.11) passed 2026-09-22**
 
-**Blockers cleared 2026-09-21 (§XLV). Task list drafted 2026-09-21, awaiting Captain Bob's
-review — none started.** Shape (§XXXIV.3, amended by §XLV): build the negotiated pub/sub
-plumbing inert, then cut over `BLK-ATTACH-EVENT` alone, then remaining types one at a time,
-under §XXXIV.2's partition rule — one message type owned by exactly one layer, no message
+**Blockers cleared 2026-09-21 (§XLV).** Shape (§XXXIV.3, amended by §XLV): build the negotiated
+pub/sub plumbing inert, then cut over `BLK-ATTACH-EVENT` alone, then remaining types one at a
+time, under §XXXIV.2's partition rule — one message type owned by exactly one layer, no message
 shared. **Stop condition (§XXXIV.6): `dict_hash` diverging across ISAs, or Stage B evidence
-(ledger + `stadium_conserved()`) going false — re-plan, do not push on.**
+(ledger + `stadium_conserved()`) going false — re-plan, do not push on.** Never triggered across
+any of tasks 3.1–3.10's own acceptance runs. See task 3.11's own entry below for the closing
+account.
 
 - [x] **B1** — **CLEARED 2026-09-21 by `FABRIC-3.5.md` §XLV.1**: negotiated pub/sub channels —
       one common channel, private channels by request/grant/deny, ACK/NACK throughout. Overrules
@@ -1194,11 +1195,75 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
       call sites in `mama_forth_words.c`) and is deliberately deferred to its own task rather
       than interleaved with this one's live debugging. Not tracked as a numbered task yet —
       pick a number when it's actually scheped.
-- [ ] **3.10** — **Stage D: `ELEVATE-REQUEST` (type 8)**, the same one-type-per-task check as
+- [x] **3.10** — **Stage D: `ELEVATE-REQUEST` (type 8)**, the same one-type-per-task check as
       3.8/3.9. Split out as its own explicit item (previously bundled into 3.9's own text without
       a checkbox) per this document's own carry-forward-discipline rule (§XXXI.2).
-- [ ] **3.11** — **Phase 3 gate.** No FORTH-owned live message types remain; Stage B evidence
+      2026-09-22 · **Closed.** Final acceptance: `logs/20260922-165122/amd64/`,
+      `logs/20260922-165333/aarch64/`, `logs/20260922-165635/riscv64/` — all three reach
+      `[zuse@Hera] ok>`, zero `UNKNOWN WORD`, `mkcapsule --lint capsules/` clean (38 files, 0
+      violations). **`dict_hash` identical across all three architectures for every VM**
+      (`0x25052a7b8d02b81e` Hera / `0x7011e083c3259321` Hermes / `0x26317a2a0d37e4b0` Hestia /
+      `0xc14d3370d46fcf08` Artemis) — changed from every prior acceptance run in this document
+      (`word_count` 529→530, one new C word registered) but consistent across all three
+      architectures, matching §XXXIV.6's own rule that a *changing* hash is expected and only
+      *divergence* between architectures is the stop condition.
+
+      **Reachability verified live before writing any code, per `advisor()`'s own steer** — not
+      grep alone (`FABRIC-3.5.md §XXXV.0`/trap #2): `grep -rn "SEND-ELEVATE" capsules/
+      experiments/ docs/` found zero callers of `SEND-ELEVATE-REQUEST` anywhere (matching the
+      `init-l8-*` zero-reference precedent, §XXII.2), so this task genuinely has no automatic
+      trigger — but `FIND SEND-ELEVATE-REQUEST`, `FIND ELEVATE-GRANT`, and `FIND CH-REQUEST`
+      (correct usage: `FIND` parses the next word from input directly, not `S" ..." FIND` — the
+      latter faulted live, corrected mid-check) all resolved to real, nonzero dictionary
+      addresses on a live Hera boot. **Correction to a prior finding, found live in the course of
+      this check:** task 3.8's own write-up claimed "Hera's own pre-existing inability to load
+      `common:messaging.4th`" — false. `capsules/init.4th` (Hera's own `MAMA_INIT` capsule)
+      loads `common:messaging.4th` at line 21, and `SEND-ELEVATE-REQUEST` lives and works in her
+      dictionary right now. Task 3.8's own actual scope (only the reply leg was real FORTH
+      messaging traffic) stands unaffected by this correction — the false claim was about *why*,
+      not about *what* task 3.8 did. `SEND-ELEVATE-REQUEST` is a real, complete, directly-callable
+      entrypoint (H.5/H.8's own design: any VM wanting word-ACL elevation calls it with its own
+      pubkey and the target word name) with no current automatic trigger, not dead/unreachable
+      code — verified live by calling it directly from Hera's own console on all three
+      architectures: `0 0 0 0 S" DUP" SEND-ELEVATE-REQUEST` (a deliberately-invalid all-zero
+      pubkey, so `ELEVATE-GRANT` correctly refuses without granting anything real — the check is
+      that the full pipeline runs, not that a grant succeeds; confirmed `DUP` itself unaffected
+      afterward). Evidence line fires immediately, no idle-pump delay needed here (unlike task
+      3.9's WIREBIND-identity target): Hera is both sender and receiver in this test, and she is
+      always being actively interpreted, matching task 3.8's own Hera-target precedent exactly.
+
+      **What actually cut over.** `SEND-ELEVATE-REQUEST` (`messaging.4th`, block 5040) no longer
+      ends in `ELEVATE-REQUEST MY-CH-ID @ 0 ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ CH-REQUEST`; it now
+      ends in `ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ KH-ELEVATE-SEND DROP`, a new C word (`repl.c`)
+      wrapping `sk_hermes_send_one()`, registered unconditionally for every VM
+      (`sk_repl_register_words()`, same site `KH-BLK-ATTACH-SEND` already uses). `from`/`to` are
+      derived from the calling VM and `sk_get_mama_vm()` directly in C, never taken from the
+      stack — a real correctness improvement over `CH-REQUEST`'s own "initiator-only gate...
+      refuses if `from` doesn't match `MY-CH-ID`", which existed only because a caller *could*
+      pass the wrong stack value; deriving `from` from the C-level calling VM's own identity makes
+      that spoof structurally impossible rather than merely gated. `SK_HERMES_MSG_TYPE_ELEVATE_
+      REQUEST` (`kernel_hermes.h`) deliberately reuses `ELEVATE-REQUEST`'s own value (8), same
+      partition-rule reasoning as tasks 3.8/3.9. Delivery is unchanged task 3.4 machinery
+      (`sk_hermes_drain_checkpoint()` → `vm_interpret()` on Hera with the payload text, which
+      calls `ELEVATE-GRANT` exactly as before). No new static-buffer lifetime caveat this time —
+      the payload-aliasing fix landed before this task started, so `g_kh_elevate_buf` needed no
+      `g_kh_blk_attach_buf`/`g_kh_console_cmd_buf`-style deferred-defect note.
+
+      **Found, not fixed (Captain Bob's Law): `CH-REQUEST` (`messaging.4th` block 5031) is now
+      dead code.** It had exactly one real caller (`SEND-ELEVATE-REQUEST`'s own old tail, just
+      removed); nothing else in `capsules/` calls it. Left in place, not removed — orphaning it is
+      a side effect of this cutover, not this task's own scope to clean up.
+- [x] **3.11** — **Phase 3 gate.** No FORTH-owned live message types remain; Stage B evidence
       holds across a full boot on all three ISAs. **Do not start Phase 4 until this passes.**
+      2026-09-22 · **Passes.** Tasks 3.8 (`BLK-ATTACH-EVENT`), 3.9 (`CONSOLE-CMD-EVENT`), and 3.10
+      (`ELEVATE-REQUEST`) — messaging.4th's entire live/reserved type space except the two
+      already-dead sentinels (`MSG-NACKED`/`MSG-DELIVERED`, never live to begin with per task
+      0.1/0.4) and `PAUSE-EVENT`/`RESUME-EVENT`/`KILL-EVENT` (Category A/dead, same source) — are
+      all real kernel-Hermes cutovers now, each independently verified live on all three
+      architectures with real evidence. Stage B's own conservation evidence (`stadium_conserved()`
+      holding across every cutover's own acceptance run, task 2.7's four-term form) has held
+      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