Stage C: cut over BLK-ATTACH-EVENT alone -- FABRIC-3.6.md task 3.8

The reply leg (Artemis -> Hera ack) that used to flow through
common:messaging.4th's MSG-SEND/MSG-TICK now goes through
kernel-Hermes's sk_hermes_send_one()/sk_hermes_drain_checkpoint()
instead -- FORTH Hermes never sees a BLK-ATTACH-EVENT message again
(SXXXIV.2's partition rule). The request leg was never real FORTH
messaging traffic to begin with (a direct VM-EXEC, no type tag,
forced by Hera's own inability to load common:messaging.4th), so it
is untouched.

New KH-BLK-ATTACH-SEND (repl.c) wraps sk_hermes_send_one(), reached
from capsules/artemis/init.4th's HERA-BLK-ATTACH-REQ. Delivery reuses
task 3.4's already-wired sk_hermes_drain_checkpoint(); BLK-ATTACH-ACK
itself is unchanged, just reached by a different layer.
SK_HERMES_MSG_TYPE_BLK_ATTACH deliberately reuses BLK-ATTACH-EVENT's
own value (9) to document this as a cutover of the same message, not
a new one.

Two real bugs found on the way, both recorded in FABRIC-3.6.md's
findings log:
- A popped FORTH CREATE-buffer address was raw-cast to a host pointer
  instead of going through vm_ptr() -- silently read all-zero memory,
  no crash, no error, just a message that arrived and did nothing.
  Fixed; the rule and its exception (repl.c's own dev-addr is
  legitimately a raw pointer, formatted that way by its own pushing
  code) are written up for the next FORTH-facing C word.
- A separate, genuine hang on the very first live exercise of this
  path, never reproduced across ten subsequent boots. Reported, not
  chased -- not blocking, per the task's own check being otherwise
  fully satisfied.

Also found live: log_message() is invisible in this build's actual
serial-log capture at every level -- settled on a single
console_println in the real drain target instead, one line per real
USB attach, not a hot-path.

Final acceptance (logs/20260922-105501, -105758, -110304, disk images
reset before each): dict_hash identical across all three
architectures for every VM, zero UNKNOWN WORD, mkcapsule --lint
clean, real ledger+stadium_conserved(Artemis)=true evidence on every
boot.

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

include/starkernel/vm/kernel_hermes.h

@@ -677,12 +677,27 @@ int sk_hermes_reassemble(SkHermesMessage **chunks, int n_chunks,
 #define SK_HERMES_MSG_TYPE_ACK        22
 #define SK_HERMES_MSG_TYPE_NACK       23
 #define SK_HERMES_MSG_TYPE_CH_CLOSE   24
-/* Chosen clear of messaging.4th's own live/reserved type space
- * (PAUSE-EVENT=2, RESUME-EVENT=3, KILL-EVENT=4, CONSOLE-CMD-EVENT=7,
- * ELEVATE-REQUEST=8, BLK-ATTACH-EVENT=9, MSG-NACKED=253,
- * MSG-DELIVERED=255) -- kernel-Hermes remains its own inert, parallel
- * type space until a real cutover (task 3.8+) makes the two coincide;
- * not itself a ruling, just room left deliberately. */
+
+/* SK_HERMES_MSG_TYPE_BLK_ATTACH (FABRIC-3.6.md task 3.8, Stage C) --
+ * DELIBERATELY the same numeric value as messaging.4th's own
+ * BLK-ATTACH-EVENT constant (9), not a fresh kernel-Hermes-space number
+ * like the five above. SXXXIV.2's partition rule is "one owner per
+ * message type, never shared" -- it is about which LAYER holds the
+ * message, not about the two layers needing disjoint numbering. Once
+ * kernel-Hermes is this type's sole owner, keeping the same value
+ * documents that this is a cutover of the SAME logical message, not a
+ * new one invented alongside it. */
+#define SK_HERMES_MSG_TYPE_BLK_ATTACH 9
+
+/* The five negotiation types above (20-24) were chosen clear of
+ * messaging.4th's own live/reserved type space (PAUSE-EVENT=2,
+ * RESUME-EVENT=3, KILL-EVENT=4, CONSOLE-CMD-EVENT=7, ELEVATE-REQUEST=8,
+ * BLK-ATTACH-EVENT=9, MSG-NACKED=253, MSG-DELIVERED=255) precisely
+ * because none of them had a real cutover yet -- kernel-Hermes stayed
+ * its own inert, parallel type space for those. SK_HERMES_MSG_TYPE_
+ * BLK_ATTACH above is the deliberate exception: task 3.8 IS that type's
+ * real cutover, so it reuses BLK-ATTACH-EVENT's own value (9) rather
+ * than picking a fresh one. */
 
 /* sk_hermes_channel_request - requester asks target for a new private
  * channel. A point-to-point CH_REQUEST (sk_hermes_send_one(), tagged