Migrate Hera->Artemis storage-attach to a real message round-trip

Hera still polls xHCI and sig-checks attached drives, but the storage
registration step (blk_subsys_attach_device(), now wrapped as the
BLK-ATTACH primitive) moves to Artemis's own dictionary, reached via
HERA-BLK-ATTACH-REQ/BLK-ATTACH-ACK (VM-EXEC, since Hera can't load her
own messaging.4th -- see the doc comment in repl.c). Identity birth
(Zuse genesis / WIREBIND) is deferred until the ack confirms storage
actually succeeded, instead of running synchronously underneath a
storage call that might fail ("wait for ack, safer for identity data").

Caught and fixed a real bug live during acceptance testing: Artemis's
ACK-APPEND-NUM fed a single-cell value into <# #S #> (which expects a
double-cell pair), causing a stack underflow the first time
HERA-BLK-ATTACH-REQ ran. Fixed with the same `0 SWAP` convention every
other numeric-append helper in this codebase already uses.

Verified booting clean to (zuse) ok> with no VM-EXEC errors on all
three architectures (amd64/aarch64/riscv64).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78

src/word_source/block_words.c

@@ -613,6 +613,28 @@ static void block_word_owner_fetch(VM *vm) {
     vm_push(vm, packed);
 }
 
+/* BLK-ATTACH ( dev-addr -- ok? ) : registers an already-open blkio_dev_t
+ * (its raw C pointer, passed as a cell -- the same "embed a pointer as a
+ * number in generated FORTH text" pattern VM-EXEC/the console relay
+ * already use) into the block subsystem's unified LBN address space via
+ * blk_subsys_attach_device(). This is the storage/persistence half of a
+ * USB drive attach -- Artemis's own domain -- split out from repl.c's
+ * attach loop so it can run as a message target (capsules/artemis/
+ * init.4th's HERA-BLK-ATTACH-REQ) instead of a direct C call, per Captain
+ * Bob's 2026-09-07 messaging-migration decision: Hera keeps polling and
+ * sig-checking, but no longer performs this step herself. dev-addr is
+ * trusted as a valid blkio_dev_t* from a live attach in progress -- there
+ * is no way to validate an arbitrary pointer from FORTH space, matching
+ * every other raw-pointer word this driver already exposes (e.g.
+ * dictionary_manipulation_words.c's >LINK/LINK>/CFA). */
+static void block_word_blk_attach(VM *vm) {
+    if (vm->dsp < 0) { vm->error = 1; return; }
+    cell_t dev_addr = vm_pop(vm);
+    struct blkio_dev *dev = (struct blkio_dev *)(uintptr_t)dev_addr;
+    int rc = blk_subsys_attach_device(dev);
+    vm_push(vm, (rc == BLK_OK) ? 1 : 0);
+}
+
 /* --- Registration ----------------------------------------------------- */
 
 /*
@@ -638,4 +660,5 @@ void register_block_words(VM *vm) {
     register_word(vm, "BLK-ACL-TTL@", block_word_acl_ttl_fetch);
     register_word(vm, "BLK-ACL-TTL!", block_word_acl_ttl_store);
     register_word(vm, "BLK-OWNER@", block_word_owner_fetch);
+    register_word(vm, "BLK-ATTACH", block_word_blk_attach);
 }