FABRIC.md: rule and restate acceptance for item 4.2

Punch list §25 item 4.2 complete (scoping only, no code).
Two rulings taken before implementation starts: the stadium_owner[idx]
fix (§25.7) is explicitly folded into 4.2's scope rather than split out,
since a second VM with a quota is what makes the bug live; the C/FORTH
boundary is a small new kernel-only FORTH primitive layer
(STADIUM-ADMIT/EVICT/RES@/RES-PULL/RES-PUSH), registered like BIRTH/RUN/USE,
the only new C this item may add per HERMES.md's language constraint.
Surfaces two open questions for implementation time rather than resolving
them by assumption: the STADIUM_BEHAVIOUR_DELIVER/EXPIRE mapping for
messages/channels, and whether this dissolves HERMES.md's G8 deferral.
States Done-when acceptance, including the explicit effort-number report
§10 calls for.

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

FABRIC.md

@@ -3302,6 +3302,69 @@ document and committing that amendment as its own item.*
   >   (Q48_ONE=65536)` — the conservation invariant closes exactly.
 - [ ] **4.2 — Hermes native on the Stadium.** The proving ground; produces the effort
   number. *Refs:* §10.
+
+  > **Two rulings taken before work starts, 2026-08-05:**
+  > 1. **`stadium_owner[idx]` fix folded into this item's scope**, by explicit Captain Bob
+  >    authorization (not a §25.0-rule-3 violation — this is the same "required for the
+  >    item's own correctness" precedent as 4.1's FORGET hook). `stadium_admit()` writes
+  >    `stadium_owner[idx]` on neither the free-list-pop nor the eviction-fallback path;
+  >    harmless while Hera is the only VM with a quota, but this item puts a second VM
+  >    (Hermes) on the Stadium, and without the fix a resident's evict-credit flows to the
+  >    wrong VM's reservoir. Fix ships as part of this item's commit, called out separately
+  >    in the acceptance below so it doesn't hide inside the migration diff.
+  > 2. **C/FORTH boundary: new thin FORTH-callable primitives**, registered in C exactly
+  >    like `BIRTH`/`RUN`/`USE` (kernel-only, not shared/vendored), justified under
+  >    `.claude/CLAUDE.md`'s "raw hardware access, atomics, syscalls, freestanding kernel
+  >    ops" exception to "compose in FORTH first." Candidate surface — confirmed, not yet
+  >    implemented:
+  >    ```
+  >    STADIUM-ADMIT     ( identity heat behaviour -- cell | -1 )
+  >    STADIUM-EVICT      ( cell -- flag )
+  >    STADIUM-RES@       ( vm-id -- heat )
+  >    STADIUM-RES-PULL   ( vm-id qty -- heat )
+  >    STADIUM-RES-PUSH   ( vm-id heat -- )
+  >    ```
+  >    Exact stack signatures and error handling to be finalized during implementation, not
+  >    invented here. `HERMES.md`'s non-negotiable — all Hermes-side logic in StarForth,
+  >    zero new C beyond this primitive layer — still applies; these five words are the
+  >    entire C surface this item may add.
+  >
+  > **Open, surfaced not resolved:** mapping Hermes's message/channel lifecycle onto the
+  > closed `STADIUM_BEHAVIOUR_*` set (`MIGRATE`/`DELIVER`/`EXPIRE`/`COOL`) — `DELIVER` and
+  > `EXPIRE` currently have dispatch cases in `stadium.c` but no consumer, and were
+  > apparently reserved for exactly this. Which tag maps to a message and which (if either)
+  > to a channel is implementation work for this item, not decided here. Also open: whether
+  > migrating message/channel heat into the Stadium's conserved 1.0 dissolves or changes
+  > `HERMES.md`'s G8 note (`HERMES-K`/`K-FLEET` integration deferred pending cross-VM return
+  > values) — the reservoir mechanism (`stadium_reservoir_pull`/`push`) already crosses VM
+  > boundaries, so this may no longer be blocked the way G8 describes. Raise during
+  > implementation; do not resolve by assumption.
+  >
+  > *Done when:*
+  > - The five `STADIUM-*` FORTH primitives exist, are kernel-only (not in the shared/
+  >   vendored word set), and are exercised by at least one Hermes word each.
+  > - `stadium_owner[idx]` is written correctly on both the free-list-pop and
+  >   eviction-fallback paths in `stadium_admit()`, verified by a resident cell's
+  >   evict-credit landing in the correct VM's reservoir with two VMs holding quotas
+  >   (Hera + Hermes) — not just asserted from reading the code.
+  > - Hermes's message and channel lifecycle (`MSG-ALLOC`/`MSG-FREE-NODE`, `CH-ALLOC`/
+  >   `CH-FREE-NODE`, `MBR-ALLOC`/`MBR-FREE-NODE`) run entirely through Stadium admission/
+  >   eviction — no parallel free list, no parallel heat field. Per §11, this is atomic:
+  >   `MSG-HEAT@/!`, `MSG-COOL-ONE`, `MSG-COOL-ALL`, `CH-HEAT@/!`, `CH-COOL-ALL`,
+  >   `CH-TOTAL-HEAT`, `MSG-TOTAL-HEAT` either come out in this same change or are rewritten
+  >   to read/write the Stadium cell instead of a local field — never both mechanisms live
+  >   at once.
+  > - Blocks 4110–4113 (Artemis) are untouched, per `HERMES.md`'s block-map lock. Any new or
+  >   changed Hermes block is verified with `mkcapsule --lint` before commit, per
+  >   `experiments/bare_metal/README.md`.
+  > - The POST suite (regression gate per §10) passes.
+  > - **The effort number is recorded explicitly** — per §10, "what Hermes costs is the
+  >   multiplier for everything else." Report at minimum: wall-clock/session time spent,
+  >   lines changed (FORTH + the five-primitive C surface, split out), and file count
+  >   touched, so 4.3/4.4 can be estimated from a real data point rather than guessed.
+  > - All three architectures boot to `ok>`/`zuse)ok>` with logs under `logs/`, and
+  >   Hermes's own conservation check (K≡1.0 across messages + channels + reservoir) closes
+  >   exactly, reported the same way item 4.1 reported `resident_sum`/`reservoir`/`sum`.
 - [ ] **4.3 — Console.** Settles 1.11 as part of the work. *Refs:* §17.5.
 
   > **Note, 2026-08-05: Captain Bob wants a discussion before any work starts on this item.**