starkernel: item 3.6 -- Hera as patron zero, pinned (Phase 3 core complete)

Punch list §25 item 3.6 complete. Phase 3 (§25.4) core is now done:
items 3.1-3.6 all closed.

stadium_evict() now panics via sk_hal_panic() if a resident cell 0
(Hera, patron zero by construction of §6's boot order) is ever
selected for eviction. Placement is deliberate: the check runs before
the pin/contains refusal checks, not after -- if it ran after, a
wrongly-cleared pin would let the ordinary refusal path quietly return
-1 instead of ever reaching the panic, defeating the point of a check
that's supposed to be independent of pin holding.

Per §20.5 #3's explicit wording, not implemented as a filter:
stadium_admit()'s least-dense search is unchanged, still relying on
the general pin skip from item 3.5. Adding a second filter there would
have done exactly what that section warns against ("filtering hides
the bug, asserting reports it").

The panic path is, and will remain, unexercised by the acceptance
mechanism: sk_hal_panic() halts the machine, and triggering it
deliberately is incompatible with the three-arch boot being this
project's sole acceptance test. Correctness rests on the placement
argument, not a test -- same honesty precedent as items 3.4 and 3.5's
other unexercised paths.

Verified: three-architecture boot (amd64, aarch64, riscv64), all
reaching ok> with identical dict_hash=0x3d4e1daf289da94f matching the
item-3.5 baseline.

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

FABRIC.md

@@ -2855,9 +2855,46 @@ document and committing that amendment as its own item.*
   > `dict_hash=0x3d4e1daf289da94f`, matching the item-3.4 baseline — amd64
   > (`logs/20260804-172516`), aarch64 (`logs/20260804-172556`), riscv64
   > (`logs/20260804-172651`).
-- [ ] **3.6 — Hera as patron zero, pinned.** Assert at the eviction site; selecting Hera is
+- [x] **3.6 — Hera as patron zero, pinned.** Assert at the eviction site; selecting Hera is
   a panic, not a filtered candidate. *Refs:* §20.5 #3.
 
+  > **DONE 2026-08-04.** `STADIUM_HERA_CELL_INDEX` (0) documented as a positional invariant
+  > from §6's boot order (Hera is the first patron admitted), not a runtime identity check —
+  > nothing births anything yet, Hera included, so the index is never actually occupied
+  > today. `stadium_evict()` now panics via `sk_hal_panic()` (already `noreturn`, matching
+  > `arena.c`'s existing use) if a *resident* cell 0 is ever selected.
+  >
+  > **Placement matters and was deliberate:** the assertion runs *before* the pin and
+  > `contains` refusal checks, not after. §20.5 #3 asks for a check independent of pin
+  > holding — if it ran after the pin check, a wrongly-cleared pin would let the ordinary
+  > refusal path quietly return `-1` instead of ever reaching the panic, silently swallowing
+  > exactly the failure this item exists to surface.
+  >
+  > **Per the item's own wording, not implemented as a filter:** `stadium_admit()`'s
+  > least-dense search is unchanged — it still relies on the general pin skip (item 3.5) to
+  > avoid selecting a pinned Hera in the first place. §20.5 #3 explicitly: "state it as an
+  > assertion at the eviction site, not as a filter on the candidate set — filtering hides
+  > the bug, asserting reports it." Adding a second, redundant filter in the search loop
+  > would have done exactly what that line warns against.
+  >
+  > **The panic path itself is, and will remain, unexercised by the acceptance mechanism.**
+  > `sk_hal_panic()` halts the machine — triggering it deliberately would mean the kernel
+  > cannot reach `ok>`, which is incompatible with the three-arch boot being this project's
+  > sole acceptance test. Nothing calls `stadium_evict()` yet regardless (same as items 3.4
+  > and 3.5), so this boot run does not exercise the check either way. Correctness rests on
+  > the placement argument above, not a test.
+  >
+  > **Regression: clean.** All three architectures boot to `ok>` with identical
+  > `dict_hash=0x3d4e1daf289da94f`, matching the item-3.5 baseline — amd64
+  > (`logs/20260804-173311`), aarch64 (`logs/20260804-173350`), riscv64
+  > (`logs/20260804-173446`).
+  >
+  > **Phase 3 core complete.** Items 3.1–3.6 close out §25.4. The Stadium has a validated
+  > 64-byte cell, boot-time allocation sized from a real memory query, a closed
+  > compiler-enforced behaviour set, density as a read, admission/eviction with the mass and
+  > Hera invariants both enforced, and nothing yet calling any of it — Phase 4 (§25.5) is
+  > where real patron kinds (words first, per item 4.1) start migrating onto it.
+
 ---
 
 ## 25.5 Phase 4 — Migrate the subsystems