starkernel: item 3.1 reopened -- two Kconfig symbols items 1.1/1.4 deferred here

Punch list §25 item 3.1 re-closed after reopening.

Items 1.1 and 1.4's resolutions both explicitly named this item as
where their Kconfig symbols would be implemented, but 3.1's own stated
scope never mentioned them, so the first close missed both:

- STADIUM_CONTAINS_DEPTH_MAX (default 5) -- item 1.1's contains-chain
  depth cap. No consumer yet; reap-gating enforcement is item 3.5.
- STADIUM_CAPACITY_TICK (default 1000) -- item 1.4's capacity
  arbitration cadence in virtual ticks. No consumer yet; capacity
  arbitration itself is not on the punch list.

Both added following STADIUM_MAX_VM_COUNT's exact pattern:
Kconfig.kernel entry, Makefile.starkernel kconfig_int +
VM_FEATURE_FLAG_VARS forwarding, starforth_config.h fallback default.
stadium.h now includes starforth_config.h and carries two more
C99-portable compile-time checks proving both symbols are defined and
sane, same discipline as the byte-count checks. Declaration only --
not inventing the consuming logic to close this out early.

Verified: three-architecture boot (amd64, aarch64, riscv64), all
reaching ok> with identical dict_hash=0x3d4e1daf289da94f, re-run after
the reopening.

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

FABRIC.md

@@ -2674,6 +2674,37 @@ document and committing that amendment as its own item.*
   > remains unanswered — there is no message patron struct anywhere in this tree yet
   > (messages are undesigned future work), so there is nothing concrete to check the 32-byte
   > inline payload against. Not fabricated a number to close this; left open.
+  >
+  > **REOPENED 2026-08-04.** While reading context for item 3.2, found that two earlier
+  > resolutions had explicitly named *this* item as where their Kconfig symbols would be
+  > implemented — item 1.1 (line ~2400, "exposed as a Kconfig symbol, named at implementation
+  > time in item 3.1", the `contains`-chain depth cap, default 5) and item 1.4 (§22.4 and its
+  > own resolution, "Kconfig-tunable at implementation (item 3.1)", the capacity-tick
+  > constant, default 1000). Neither made it into the work above, because 3.1's own stated
+  > scope ("cell and header") never mentioned them — the promise lived only in items 1.1 and
+  > 1.4's text. Captain Bob ruled: reopen, add both here (Phase 3 is implementation, unlike
+  > Phase 1's paper-only items — item 1.7's own nesting-depth Kconfig symbol was correctly
+  > left undone at Phase 1, by contrast). Declaration only, matching how
+  > `STADIUM_MAX_VM_COUNT` was introduced in item 2.2's WIP commit before its consuming logic
+  > existed: `STADIUM_CONTAINS_DEPTH_MAX` (default 5) has no consumer yet — reap-gating on
+  > `contains` is item 3.5's scope. `STADIUM_CAPACITY_TICK` (default 1000) has no consumer
+  > yet either — capacity arbitration isn't on the punch list at all yet. Not inventing that
+  > logic here; only the two symbols.
+  >
+  > **RE-CLOSED 2026-08-04.** Both symbols added following `STADIUM_MAX_VM_COUNT`'s exact
+  > pattern: `Kconfig.kernel` entry, `Makefile.starkernel` `kconfig_int` +
+  > `VM_FEATURE_FLAG_VARS` forwarding, `starforth_config.h` fallback default (needed for this
+  > no-`.config` build, same gap the original `STADIUM_MAX_VM_COUNT` WIP commit hit and item
+  > 2.2 fixed). `stadium.h` now includes `starforth_config.h` and carries two more
+  > C99-portable compile-time checks (`> 0`, not byte-count) proving both symbols are defined
+  > and sane in the same translation unit as the cell checks. `contains`'s field comment now
+  > references `STADIUM_CONTAINS_DEPTH_MAX` by name. Recompiled `stadium.c` standalone
+  > (clean) before the full run.
+  >
+  > **Regression: clean, re-run after reopening.** All three architectures boot to `ok>`
+  > with identical `dict_hash=0x3d4e1daf289da94f` -- amd64 (`logs/20260804-151032`), aarch64
+  > (`logs/20260804-151115`), riscv64 (`logs/20260804-151222`).
+
 - [ ] **3.2 — Boot-time allocation.** One global cell array, sized from the memory budget,
   before any VM exists. *Refs:* §6, §17.6, §22.3.
 - [ ] **3.3 — Behaviour enumeration and dispatch.** Closed tag set fixed at build time.