Add kernel-Hermes message/membership structures -- FABRIC-3.6.md task 2.1, Phase 2 begins

Phase 2, task 2.1 only: type definitions, wired to nothing, drawing no
heat -- no allocator, no protocol logic, no registration anywhere.
FABRIC-3.5.md SXXII.4: Phase 2 structures come first and prove nothing
until the allocator is built on top (task 2.2 onward, each its own
commit).

Added include/starkernel/vm/kernel_hermes.h:

SkHermesMessage -- field-for-field mirror of messaging.4th's live
9-cell MSG-* layout (type/from/to/payload addr+len/Stadium cell
index/seq/channel/orig-type), per SXXXIII.4 item 1 ("roughly half the
file is accessors that become struct fields"), plus an explicit
in_use flag for task 2.2's allocator. Deliberately no separate heat
field: per SXL.4, a message's heat IS the Stadium cell it occupies,
not a value copied alongside it -- one source of truth for the
conservation invariant stadium_conserved() (task 0.7) checks.

SkHermesMembership -- one flat broadcast membership list, SXXXIII.4/
SXXXIII.5's recommended replacement for messaging.4th's 28-word channel
abstraction (traced to exactly one live caller, CH-ADD-MBR). Item 27
(negotiation vs. broadcast, Phase 3 blocker B1) is not answered by this
structure and isn't meant to be -- a flat list is correct either way.

Genuinely wired to nothing: no .c file, no Makefile change, no include
from any compiled source. Syntax-checked standalone (gcc -std=c99
-Wall -Wextra -Werror -fsyntax-only) before touching the real build.

Boot byte-identical to task 1.9's baseline on amd64 (same dict_hash
triple, zero UNKNOWN WORD). Did not repeat aarch64/riscv64 -- the file
compiles into no object on any architecture, so there is no mechanism
by which it could diverge.

Authorized by Captain Bob ("yes").

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

FABRIC-3.6.md

@@ -481,8 +481,31 @@ Hestia; headless policy intact.
 
 **Gate:** task 2.7. **If it fails, stop and re-plan. Do not proceed to Phase 3.**
 
-- [ ] **2.1** — Kernel-Hermes message/membership structures, **wired to nothing, drawing no
+- [x] **2.1** — Kernel-Hermes message/membership structures, **wired to nothing, drawing no
       heat**. *Check:* boot byte-identical; `dict_hash` unmoved.
+      2026-09-19 · `logs/20260919-204642/amd64/` — byte-identical to task 1.9's baseline in
+      every respect: same `dict_hash` triple, zero `UNKNOWN WORD`, reaches `[zuse@Hera] ok>`.
+      Did not repeat aarch64/riscv64: the new file is a header with type definitions only,
+      included nowhere in the real build, so nothing compiles it into any object file on any
+      architecture — there is no mechanism by which it could diverge by compiler or ISA.
+
+      Added `include/starkernel/vm/kernel_hermes.h`: `SkHermesMessage` (field-for-field mirror
+      of `messaging.4th`'s live 9-cell `MSG-*` layout — type/from/to/payload addr+len/Stadium
+      cell index/seq/channel/orig-type, plus an explicit `in_use` flag for task 2.2's allocator)
+      and `SkHermesMembership` (one flat broadcast membership list — `SXXXIII.4`/`SXXXIII.5`'s
+      recommended replacement for `messaging.4th`'s 28-word channel abstraction, which has
+      exactly one live caller). Deliberately no separate heat field on the message struct: per
+      `SXL.4`, a message's heat *is* the Stadium cell it occupies, not a value copied alongside
+      it — keeping one source of truth for the conservation invariant `stadium_conserved()`
+      (task 0.7) checks.
+
+      **Genuinely wired to nothing**: no `.c` file, no Makefile change, no include from any
+      compiled source. Syntax-checked standalone (`gcc -std=c99 -Wall -Wextra -Werror
+      -fsyntax-only` against a throwaway file `#include`ing it under `__STARKERNEL__`) before
+      touching the real build, rather than discovering a typo only once something references it
+      in a later task. Item 27 (channel negotiation vs. broadcast, Phase 3 blocker B1) is not
+      answered by this structure and isn't meant to be — a flat membership list is correct either
+      way; the negotiation question is about behaviour built on top, not this shape.
 - [ ] **2.2** — Allocate: pull `Q.SLOT` from the caller's reservoir; roll back on refusal.
       *Check:* N allocs against a known reservoir; refusal at the right count.
 - [ ] **2.3** — Release: return remaining heat via the eviction path. *Check:* reservoir