Channel table + common channel, inert (B1) -- FABRIC-3.6.md task 3.2

Adds SkHermesChannel: a channel is an index into a boot-time,
stadium_max_vm_count()-sized table (same sizing pattern task 3.1
established for the switch table -- no separate numeric rule was ruled
for this table, so task 3.1's bound is extended directly, flagged as
such rather than restated as a new ruling). No name field, mirroring
messaging.4th's own nameless CH-ARENA.

The common channel (index 0) is created at boot and permanent. Hera
subscribes explicitly in kernel_main.c (she is the one VM never born
through capsule_birth_baby()); every other VM -- Tripod fleet and
future WIREBIND identities alike -- subscribes inside
capsule_birth_baby() itself, the single choke point every other birth
already passes through.

Inert: no publish, no dispatch, no ACK/NACK, no ACL hook (tasks 3.3,
3.6, 3.7). Verified live on all three architectures: channel table
sized to 50/202/50 slots (matching switch-signal's own per-arch
sizing), common-channel fleet self-test confirms all four Tripod
members are members, and a synthetic create/subscribe/unsubscribe/
destroy round-trip against a private topic passes, including refusing
to destroy the common channel.

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

FABRIC-3.6.md

@@ -798,10 +798,38 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
       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
+- [x] **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
       in the common channel's membership; create/destroy a synthetic private topic.
+      2026-09-22 · `logs/20260922-000447/amd64/`, `logs/20260922-000954/aarch64/`,
+      `logs/20260922-001511/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`,
+      `mkcapsule --lint capsules/` clean (38 files, 0 violations, unchanged -- no capsule
+      touched). New `SkHermesChannel` table (kernel_hermes.h/.c): a channel is an index into a
+      boot-time, `stadium_max_vm_count()`-sized array, no name field (mirrors messaging.4th's
+      own nameless `CH-ARENA`). Sizing note: SXLV.1 says the channel table has "no fixed channel
+      maximum, same reasoning as SXLV.2" but names no separate numeric rule -- extending task
+      3.1's already-ruled `stadium_max_vm_count()` bound directly (same kmalloc-at-boot shape)
+      is the smallest choice consistent with what was ruled; flagged in the header comment as an
+      engineering extrapolation, not restated as a separate Captain Bob ruling. Common channel
+      (index `SK_HERMES_CHANNEL_COMMON` = 0) created in `sk_hermes_channels_boot_init()`, called
+      from `kernel_main.c` right after the switch-signal boot init; Hera subscribed explicitly
+      right after `stadium_birth_hera()` (she is the one VM never born through
+      `capsule_birth_baby()`); every other VM (Tripod fleet and future WIREBIND identities
+      alike) subscribed inside `capsule_birth_baby()` itself, at its `VM_STATE_LIVE` completion
+      point -- the single choke point every non-Hera birth already passes through, confirmed by
+      grep (`mama_forth_words.c`, `capsule_runcap.c`, `capsule_console.c` all call it). New
+      console lines confirmed live on all three architectures: `Kernel-Hermes: N channel slots`
+      (**50 amd64, 202 aarch64, 50 riscv64** -- tracks switch-signal's own per-arch sizing
+      exactly, as expected since both derive from the same `stadium_max_vm_count()`), then after
+      all four fleet births, `Kernel-Hermes common-channel fleet self-test: PASS` (`common
+      channel members=4`, one per Hera/Hermes/Hestia/Artemis) and `Kernel-Hermes synthetic
+      private-topic self-test: PASS` (create/subscribe/is-member/unsubscribe/destroy round-trip
+      against a synthetic VM id, plus confirms a destroyed channel refuses further ops and the
+      common channel itself refuses `sk_hermes_channel_destroy()`) -- both PASS on all three
+      architectures. `dict_hash` for Hermes (`0xc95ef2d92fa0781f`) and Hestia
+      (`0xfbde9fe105fd3b3d`) identical across all three architectures, unmoved from task 3.1's
+      values (this task touches no capsule).
 - [ ] **3.3** — **Publish path, no dispatch** (§XLIII.3). Publish allocates via
       `sk_hermes_alloc()`, enqueues onto each subscriber's own pending queue, and records the
       fact; it dispatches nothing. Self-test only. *Check:* ledger audit and