Dynamic switch table (B2) -- FABRIC-3.6.md task 3.1

Replaces the fixed SK_SWITCH_MAX_SLOTS=16 compile-time array with a
boot-time, RAM-derived allocation via a new sk_vm_switch_signal_boot_init(),
kmalloc'd to stadium_max_vm_count() entries -- the same pattern
session_boot_init() already established for Stadium-derived sizing.
Every switch-signal participant is a Stadium VM, so this reuses that
bound directly rather than deriving a separate one.

Verified live on all three architectures: switch table sized to 50
slots (amd64), 202 slots (aarch64), 50 slots (riscv64) -- all well
past the old fixed cap. All three boot to [zuse@Hera] ok> cleanly;
dict_hash for Hermes/Hestia identical across architectures, unmoved
from pre-task values.

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

FABRIC-3.6.md

@@ -769,10 +769,35 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
       2026-09-21 · no commit (documentation ruling, see `FABRIC-3.5.md` §XLVI) · all five
       sub-items plus task 3.3's heat-cost point ruled by Captain Bob, all recommended defaults
       accepted.
-- [ ] **3.1** — **Dynamic switch table** (B2) **[needs ruling 3.0c]**. Read
+- [x] **3.1** — **Dynamic switch table** (B2). Read
       `SK_SWITCH_MAX_SLOTS`'s every use first; replace the constant with a boot-time,
       RAM-derived allocation (Stadium's `stadium_max_vm_count_val` pattern). *Check:* boot
       byte-identical, `dict_hash` unmoved; a synthetic test drives more than 16 slots.
+      2026-09-21 · `logs/20260921-233241/amd64/`, `logs/20260921-233814/aarch64/`,
+      `logs/20260921-234837/riscv64/` (riscv64's first attempt, `logs/20260921-234312/`,
+      timed out mid-boot on a 280s wrapper before reaching the prompt — kept per the
+      never-delete-logs convention, not a real finding, just an undersized timeout; the
+      234837 rerun with more headroom reached the prompt cleanly). All three reach
+      `[zuse@Hera] ok>`, zero `UNKNOWN WORD`. Switch-signal table sized dynamically off
+      `stadium_max_vm_count()` at boot, confirmed via a new `Switch-signal: N slots` console
+      line: **50 slots (amd64), 202 slots (aarch64), 50 slots (riscv64)** — all far above the
+      old fixed 16-slot cap, satisfying the "drives more than 16 slots" check without a
+      separate synthetic harness (real boot-time RAM sizing already clears it by a wide
+      margin). Reused `session_boot_init()`'s exact pattern (kmalloc to
+      `stadium_max_vm_count()`, called in `kernel_main.c` right after `stadium_boot_init()`,
+      before the first `sk_vm_switch_signal_register()` call). `dict_hash` for Hermes
+      (`0xc95ef2d92fa0781f`) and Hestia (`0xfbde9fe105fd3b3d`) identical across all three
+      architectures — unmoved from pre-task values, as expected (this task touches no
+      capsule). Artemis's `dict_hash` differs between the amd64 run (`0xa43d2e104ae7e451`,
+      fresh-formatted `disk/artemis.img`) and the aarch64/riscv64 runs (`0x7f18214489036b39`,
+      both *resuming* the same disk state the amd64 run left behind) — a disk-state artifact
+      of running three sequential boots against one shared image, not an architecture
+      divergence; not a §XXXIV.6 stop condition.
+      note: unrelated finding, not fixed — riscv64's boot logged three
+      `virtio_blk: vblk_io timed out` errors during Artemis's disk I/O in both riscv64
+      attempts (sectors 20/8/8 and 3224/5496/5504); boot recovered and reached the prompt
+      regardless. `virtio_blk.c` was not touched by this task. Reporting per standing rule,
+      not investigating further here.
 - [ ] **3.2** — **Channel table + common channel**, inert (B1). Dynamic table of topics, each
       with its own `SkHermesMembership`; the common channel exists from boot; every VM is
       subscribed at birth. Wired to nothing. *Check:* boot byte-identical; every born VM appears