feat(log): LOG-FLUSH -- a VM's log records reach Artemis's log ring; and the ring keeps its order when it grows

FABRIC-3 SXXXII.4's deferred LOG-FLUSH, built to the 2026-10-14 rulings
(SXXXVIII): everything a VM logs, at or above the log level, goes into its
own buffer; it goes to Artemis on LOG-FLUSH, when full, and at once on an
ERROR, as one kernel-Hermes LOG_BATCH message she writes on her own turn,
the source being the sender the kernel stamped.  Records that cannot go yet
are counted and reported with the next flush.  LOG-SHOW (Hera only) reads
the ring back -- it had no reader.

Found by the first test that filled it: ring growth overwrote the oldest
record and put blank slots inside the live range.  Fixed test first.

Three ISAs: POST 1052 passed; new parity baseline word_count=526
hash=0x82f4ae7cb2e2d424 (deliberate).  CLAUDE.md: Phase 8 PKI closed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kernel/include/starkernel/vm/kernel_hermes.h

@@ -728,6 +728,12 @@ int sk_hermes_reassemble(SkHermesMessage **chunks, int n_chunks,
  * new one invented alongside it. */
 #define SK_HERMES_MSG_TYPE_BLK_ATTACH 9
 
+/* SK_HERMES_MSG_TYPE_LOG_BATCH (2026-10-14, FABRIC-3.md SXXXVIII): a VM's
+ * log records, binary (vm_log_buffer.h), for Artemis's log ring. The one
+ * type that is not FORTH text: sk_hermes_drain_checkpoint() hands it to
+ * vm_log_batch_deliver() instead of interpreting it. */
+#define SK_HERMES_MSG_TYPE_LOG_BATCH 10
+
 /* SK_HERMES_MSG_TYPE_CONSOLE_CMD (FABRIC-3.6.md task 3.9, Stage D) --
  * same reasoning as SK_HERMES_MSG_TYPE_BLK_ATTACH above: deliberately
  * reuses messaging.4th's own CONSOLE-CMD-EVENT value (7), since this is