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>

include/starkernel/vm/kernel_hermes.h

@@ -734,15 +734,29 @@ int sk_hermes_reassemble(SkHermesMessage **chunks, int n_chunks,
  * that type's real cutover, not a fresh kernel-Hermes-space number. */
 #define SK_HERMES_MSG_TYPE_CONSOLE_CMD 7
 
+/* SK_HERMES_MSG_TYPE_ELEVATE_REQUEST (FABRIC-3.6.md task 3.10, Stage D)
+ * -- same reasoning again: reuses messaging.4th's own ELEVATE-REQUEST
+ * value (8). Reachability was verified live before this cutover, not
+ * assumed from a stale claim elsewhere in this project's own docs
+ * (task 3.8's write-up said Hera "cannot load common:messaging.4th" --
+ * false: SEND-ELEVATE-REQUEST, ELEVATE-GRANT, and CH-REQUEST all FIND
+ * live in Hera's own dictionary). No existing capsule calls
+ * SEND-ELEVATE-REQUEST -- it 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. */
+#define SK_HERMES_MSG_TYPE_ELEVATE_REQUEST 8
+
 /* The five negotiation types above (20-24) were chosen clear of
  * messaging.4th's own live/reserved type space (PAUSE-EVENT=2,
  * RESUME-EVENT=3, KILL-EVENT=4, CONSOLE-CMD-EVENT=7, ELEVATE-REQUEST=8,
  * BLK-ATTACH-EVENT=9, MSG-NACKED=253, MSG-DELIVERED=255) precisely
  * because none of them had a real cutover yet -- kernel-Hermes stayed
  * its own inert, parallel type space for those. SK_HERMES_MSG_TYPE_
- * BLK_ATTACH and _CONSOLE_CMD above are the deliberate exceptions: tasks
- * 3.8/3.9 ARE those types' real cutovers, so they reuse the FORTH-side
- * value rather than picking a fresh one. */
+ * BLK_ATTACH, _CONSOLE_CMD, and _ELEVATE_REQUEST above are the
+ * deliberate exceptions: tasks 3.8/3.9/3.10 ARE those types' real
+ * cutovers, so they reuse the FORTH-side value rather than picking a
+ * fresh one. */
 
 /* sk_hermes_channel_request - requester asks target for a new private
  * channel. A point-to-point CH_REQUEST (sk_hermes_send_one(), tagged