Stage D: CONSOLE-CMD-EVENT real cutover -- FABRIC-3.6.md task 3.9

Send-side cutover: sk_repl_dispatch_line()'s FORTH-string
"CONSOLE-CMD-EVENT 0 3 S\" ...\" 0 MSG-SEND" interpret is replaced with
a direct sk_hermes_send_one() call (SK_HERMES_MSG_TYPE_CONSOLE_CMD,
kernel_hermes.h, deliberately reusing CONSOLE-CMD-EVENT's own value 7,
same partition-rule reasoning as task 3.8's BLK-ATTACH-EVENT cutover).

Real finding along the way: kernel-Hermes's drain only ever runs as a
side effect of vm_interpret() being called on the target VM. Task
3.8's target (Hera) is always being interpreted via the interactive
REPL loop; task 3.9's target is a WIREBIND identity's own ~user VM, a
passive receiver nothing else drives. The existing idle-loop pump only
ticked VMs with the old FORTH MSG-TICK word ACL-allowed -- a VM minted
with the STD79-lockdown personality never has it, so the pump silently
skipped it forever and queued messages never delivered. Fixed by
adding an unconditional, direct sk_hermes_drain_checkpoint() call in
the same pump loop, independent of the MSG-TICK gate.

Verified live on all three architectures: WIREBIND-attach a real
identity, USE into it, type a plain console line, confirm the Stage D
evidence line and correct relayed execution result. Zero UNKNOWN WORD,
dict_hash identical across all three ISAs and matching task 3.8's own
baseline. The FABRIC-3.md-documented USE/BINDSTEP crash did not
reproduce in any of these live sessions (recorded as a finding, not
chased further).

Depends on the zuse_root_pubkey_known fix already landed in ac4d431 --
without it, WIREBIND cannot attach any identity on a fresh boot at
all, which blocked this task's own verification until found and fixed
separately.

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

include/starkernel/vm/kernel_hermes.h

@@ -689,15 +689,21 @@ 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_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
+ * that type's real cutover, not a fresh kernel-Hermes-space number. */
+#define SK_HERMES_MSG_TYPE_CONSOLE_CMD 7
+
 /* 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. */
+ * BLK_ATTACH and _CONSOLE_CMD above are the deliberate exceptions: tasks
+ * 3.8/3.9 ARE those types' real cutovers, so they reuse the FORTH-side
+ * value 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