Publish path, no dispatch -- FABRIC-3.6.md task 3.3

sk_hermes_publish() allocates one SkHermesMessage per channel member
(heat-cost ruling 2026-09-21: one message per subscriber, funded by
the publisher's own reservoir) and enqueues each onto a new
per-subscriber SkHermesPendingQueue -- found-or-created lazily by
vm_id, sized from stadium_max_vm_count() like the channel/switch
tables. Best-effort across subscribers: a failed allocation or full
queue skips and rolls back just that one subscriber, not the whole
publish -- the natural reading of "ledger and stadium_conserved() hold
across N publishes to M subscribers" (the task's own check), not a
separate ruling.

Dispatches nothing -- sk_hermes_pending_count()/peek()/pop() are the
read/drain primitives task 3.4's real checkpoint-driven drain will
build on; this task's own self-test uses them directly since no
checkpoint hook exists yet.

Verified live on all three architectures: pending-queue table sized
50/202/50 slots (tracking the channel table's own per-arch sizing), a
synthetic publish self-test (2 publishes to 3 subscribers) confirms
exact per-subscriber delivery counts, and ledger/stadium_conserved()
invariants hold both mid-publish and after manually draining every
queue back to baseline.

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

include/starkernel/vm/kernel_hermes.h

@@ -374,6 +374,83 @@ int sk_hermes_channel_member_count(int channel_id);
  * DoE/test observability, mirrors sk_vm_switch_signal_slot_capacity(). */
 int sk_hermes_channel_capacity(void);
 
+/* Boot-time allocation for the per-subscriber pending-queue table
+ * (FABRIC-3.6.md task 3.3), kmalloc'd to stadium_max_vm_count() entries --
+ * same sizing pattern as the channel table (task 3.2) and switch table
+ * (task 3.1); see kernel_hermes.c's own comment on this call for why. Must
+ * run after stadium_boot_init(). Soft failure -- returns -1 and leaves the
+ * table unallocated (every queue lookup then finds nothing) rather than
+ * halting boot. Idempotent-unsafe: call exactly once. */
+int sk_hermes_queues_boot_init(void);
+
+/*
+ * Publish path, no dispatch (FABRIC-3.6.md task 3.3, SXLIII.3; heat-cost
+ * ruling 2026-09-21: one message per subscriber, separate heat draw each --
+ * matches the existing heat-coupled allocator 1:1, no refcount machinery).
+ *
+ * sk_hermes_publish() allocates one SkHermesMessage per channel member
+ * (via sk_hermes_alloc(), funded by the publisher's own reservoir) and
+ * enqueues each onto that member's own pending queue -- FIFO, one queue
+ * per subscriber VM, found-or-created lazily on first use (same
+ * find-or-create-by-vm_id shape stadium.c's quota_slot_for_vm() and
+ * session.c's session_find() already use). It does not interpret,
+ * deliver, or otherwise dispatch anything -- draining a queue at a VM's
+ * own outermost interpret checkpoint is task 3.4's scope, not this one's.
+ *
+ * Best-effort, not atomic across subscribers: if a given subscriber's
+ * allocation or enqueue fails (reservoir exhausted, message arena full,
+ * or that subscriber's own pending queue full), that one subscriber is
+ * skipped -- the message already allocated for a failed enqueue is
+ * released back (rolled back) rather than left orphaned, but delivery to
+ * every OTHER subscriber already queued is not undone. This was not a
+ * separate Captain Bob ruling; it is the natural reading of "ledger audit
+ * and stadium_conserved() hold across N publishes to M subscribers" (task
+ * 3.3's own check) -- those invariants hold under partial delivery just
+ * as well as under all-or-nothing, and requiring atomicity across M
+ * independent reservoir-funded allocations would need a two-phase
+ * commit/rollback this task's inert scope does not call for.
+ *
+ * @param from         Publisher, whose reservoir funds every allocation.
+ * @param channel_id   Target channel (SK_HERMES_CHANNEL_COMMON or a
+ *                     channel from sk_hermes_channel_create()). Refused
+ *                     (-1) if invalid/not in use.
+ * @param type         Message type code, passed through unchanged.
+ * @param payload_addr Out-of-line payload address, passed through
+ *                     unchanged (bound/chunking is task 3.5's scope, not
+ *                     this one's -- 3.3 does not enforce a payload size
+ *                     limit).
+ * @param payload_len  Payload length in bytes, passed through unchanged.
+ * @return Count of subscribers successfully enqueued to (0..member count),
+ *         or -1 if channel_id itself was invalid.
+ */
+int sk_hermes_publish(VMUuid from, int channel_id, uint32_t type,
+                       void *payload_addr, uint32_t payload_len);
+
+/* SK_HERMES_PENDING_MAX - per-subscriber pending-queue depth. The global
+ * message arena (SK_HERMES_MSG_MAX) is the real ceiling on how many
+ * messages can ever be in flight system-wide, so sizing each VM's own
+ * queue to that same bound is a safe, simple upper limit rather than a
+ * new number to justify. */
+#define SK_HERMES_PENDING_MAX SK_HERMES_MSG_MAX
+
+/* sk_hermes_pending_count - number of messages currently queued for
+ * vm_id (0 if vm_id has no queue yet -- never having received a message
+ * is not an error). */
+int sk_hermes_pending_count(VMUuid vm_id);
+
+/* sk_hermes_pending_peek - the oldest still-queued message for vm_id, or
+ * NULL if vm_id has no queue or an empty one. Does not remove it -- task
+ * 3.4's drain logic is expected to peek, interpret, then pop. */
+SkHermesMessage *sk_hermes_pending_peek(VMUuid vm_id);
+
+/* sk_hermes_pending_pop - removes (does not release/interpret) the
+ * oldest queued entry for vm_id. Callers that also want the message's
+ * heat returned must call sk_hermes_release() on the value
+ * sk_hermes_pending_peek() returned, themselves, before or after popping
+ * -- this function only advances the queue. Refused (-1, no effect) if
+ * vm_id has no queue or an empty one. */
+int sk_hermes_pending_pop(VMUuid vm_id);
+
 #endif /* __STARKERNEL__ */
 
 #endif /* STARKERNEL_VM_KERNEL_HERMES_H */