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>

src/starkernel/repl.c

@@ -433,9 +433,61 @@ static void sk_word_kh_blk_attach_send(VM *vm) {
     vm_push(vm, rc == 0 ? 1 : 0);
 }
 
+/* FABRIC-3.6.md task 3.10 (Stage D): sized to match messaging.4th's own
+ * ELEVATE-REQ-BUF (256 bytes) -- the FORTH-side sender never builds a
+ * longer payload than that buffer allows, so this is a safe match, not
+ * an arbitrary choice. static, not stack-local: safe now that
+ * sk_hermes_send_one() copies into the message's own storage (the
+ * payload-aliasing fix landed before this task started) -- no lifetime
+ * caveat to carry forward this time, unlike g_kh_blk_attach_buf/
+ * g_kh_console_cmd_buf's own now-corrected history. */
+#define SK_KH_ELEVATE_BUF_SIZE 256
+static char g_kh_elevate_buf[SK_KH_ELEVATE_BUF_SIZE];
+
+/* KH-ELEVATE-SEND ( paddr plen -- ok? ): messaging.4th's own
+ * SEND-ELEVATE-REQUEST builds its payload (a FORTH command string
+ * calling ELEVATE-GRANT, block 5040) and hands it here instead of
+ * CH-REQUEST's old COMMON-CH/MSG-SEND path. `from`/`to` are derived the
+ * same way KH-BLK-ATTACH-SEND's own already does (the calling VM and
+ * sk_get_mama_vm() -- ELEVATE-GRANT always runs on Hera, per
+ * zuse-eligibility.4th's own header comment) -- the caller never
+ * supplies either, which is a real correctness improvement over the
+ * FORTH path it replaces: CH-REQUEST's own "initiator-only gate...
+ * refuses if from doesn't match MY-CH-ID" existed only because a caller
+ * COULD claim to be a different VM by passing the wrong stack value;
+ * deriving `from` from the C-level calling VM's own identity makes that
+ * spoof structurally impossible rather than merely gated. */
+static void sk_word_kh_elevate_send(VM *vm) {
+    if (vm->dsp < 1) {
+        log_message(LOG_ERROR, "KH-ELEVATE-SEND: stack underflow");
+        vm->error = 1;
+        return;
+    }
+    cell_t plen  = vm_pop(vm);
+    cell_t paddr = vm_pop(vm);
+    const char *src = (const char *)vm_ptr(vm, (vaddr_t)paddr);
+    size_t n = (size_t)plen;
+    VM *mama_vm = (VM *)sk_get_mama_vm();
+    size_t i;
+    int rc;
+
+    if (n >= SK_KH_ELEVATE_BUF_SIZE) n = SK_KH_ELEVATE_BUF_SIZE - 1;
+    for (i = 0; i < n; i++) g_kh_elevate_buf[i] = src[i];
+    g_kh_elevate_buf[n] = '\0';
+
+    rc = sk_hermes_send_one(vm->stadium_vm_id, mama_vm->stadium_vm_id,
+                             SK_HERMES_MSG_TYPE_ELEVATE_REQUEST, 0,
+                             g_kh_elevate_buf, (uint32_t)(n + 1));
+    if (rc != 0) {
+        log_message(LOG_ERROR, "KH-ELEVATE-SEND: kernel-Hermes refused the send");
+    }
+    vm_push(vm, rc == 0 ? 1 : 0);
+}
+
 void sk_repl_register_words(VM *vm) {
     register_word(vm, "BLK-ATTACH-ACK", sk_word_blk_attach_ack);
     register_word(vm, "KH-BLK-ATTACH-SEND", sk_word_kh_blk_attach_send);
+    register_word(vm, "KH-ELEVATE-SEND", sk_word_kh_elevate_send);
 }
 
 /*===========================================================================

src/starkernel/vm/kernel_hermes.c

@@ -628,6 +628,27 @@ int sk_hermes_drain_checkpoint(VM *vm) {
         console_println(line);
     }
 
+    /* FABRIC-3.6.md task 3.10 evidence: ELEVATE-REQUEST also has no fixed
+     * C-side handler word -- its payload is a FORTH command string
+     * calling ELEVATE-GRANT (zuse-eligibility.4th), interpreted as-is
+     * below, same shape as CONSOLE-CMD-EVENT above. Same mid-hold-instant
+     * evidence, same reasoning; `self` here is always Hera (`vm`'s own
+     * caller already resolved it that way in KH-ELEVATE-SEND, since
+     * ELEVATE-GRANT only ever runs on Hera). */
+    if (msg->type == SK_HERMES_MSG_TYPE_ELEVATE_REQUEST) {
+        uint64_t held, pulled, returned, consumed;
+        char line[160];
+        int conserved = stadium_conserved(self);
+        sk_hermes_ledger(&held, &pulled, &returned, &consumed);
+        snprintf(line, sizeof(line),
+            "Kernel-Hermes ELEVATE-REQUEST (real, Stage D): ledger held=%llu "
+            "pulled=%llu returned=%llu consumed=%llu stadium_conserved(self)=%s",
+            (unsigned long long)held, (unsigned long long)pulled,
+            (unsigned long long)returned, (unsigned long long)consumed,
+            conserved ? "true" : "FALSE");
+        console_println(line);
+    }
+
     vm->mode = MODE_INTERPRET; /* a payload is never compiled into whatever
                                 * the enclosing context was mid-defining */
     vm_interpret(vm, (const char *)msg->payload_addr);