BINDSTEP + fence-persistence fix: identity arc closed end to end

Two items, closed together per direct instruction.

1. Fence-persistence root cause, found and fixed: meta_fence_blocks
   (the field gating whether blk_meta_zone_write() can succeed at all)
   was carved out of what used to be unused padding in blk_volume_meta_t
   -- the code's own comment already documented this. disk/artemis.img
   was formatted before that field existed, so its on-disk bytes there
   have always read back as 0, and the existing-volume load path
   (blk_format_or_load_disk()) never recomputes it -- only a fresh
   format does. Every "fence write FAILED" message this entire session,
   old block-fence flow and new zuse_genesis_marker_t alike, traces to
   this one thing. Patching the field in place without redoing the rest
   of the geometry would risk corrupting whatever's already allocated
   near the top of the volume, so the only safe fix is a genuine
   reformat -- done, with explicit confirmation, since it discards
   disk/artemis.img's accumulated persistent test state (regenerated
   fresh at next boot regardless, not real data). Verified: fence write
   now succeeds with no failure suffix, and the full mint-once ->
   reboot -> reattach -> re-authenticate cycle works for the first time
   this session ("Zuse: identity confirmed from attached thumbdrive",
   ZUSE-SESSION? goes 0 -> -1 without re-minting).

2. BINDSTEP (FABRIC-3.md §F.9): capsule_wirebind_verify_cert() extracted
   as a shared function so WIREBIND (the original attach) and BINDSTEP
   (every USE of an identity-locked VM) check the exact same thing the
   exact same way. mama_word_use() now re-verifies live, not cached,
   whenever the target VM has VMIdentity.installed=1 -- reads whatever
   drive is CURRENTLY attached, re-verifies its cert, compares owner
   pubkey against the target's own installed identity, refuses on any
   mismatch or no drive attached. A target with installed=0 (Hera,
   Hermes, Artemis, any console VM) stays freely targetable, unchanged.

Two related bugs found and fixed live while testing BINDSTEP, not
assumed away: USE was Mama-only, so a console-paired session (§F.22)
had no way back to Hera at all -- any attempt to call USE from inside
a console VM hit "UNKNOWN WORD: USE", a genuine dead end. Per direct
instruction, USE isn't console-specific -- it should work VM-to-VM
universally, same as VM-EXEC already does -- so it's now registered in
register_child_vm_words() too. That alone wasn't enough: the console
relay (sk_repl_dispatch_line()) would have captured a bare USE call and
sent it to the paired user VM as a message instead of running it.
Fixed with a small suffix-match guard (sk_repl_line_calls_use()) --
real FORTH syntax always puts USE last, so a trailing-token check
reliably recognizes it without needing a full tokenizer, and it always
runs directly, never relayed.

Verified live end to end: USE on an unlocked VM works unconditionally;
USE escaping a console back to Hera now works; USE on an identity-
locked VM succeeds while its own drive is attached and is refused
once detached ("USE: FinT~user refused -- no matching identity
currently attached"). Clean 3-architecture regression, including
confirming disk/artemis.img's reformatted geometry loads correctly as
an already-recognized volume ("Artemis: LithosAnanke disk -- resuming")
on aarch64 and riscv64 too, not just the amd64 boot it was reformatted
under.

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

include/starkernel/capsule_wirebind.h

@@ -23,10 +23,33 @@
 #ifdef __STARKERNEL__
 
 #include "starkernel/homeblocks_sig.h"
+#include "starkernel/vm_identity.h"
 #include "vm.h"
 
 struct blkio_dev;
 
+/**
+ * capsule_wirebind_verify_cert - Read the cert region off dev and verify
+ * it against mama_vm's own Zuse identity. Shared by both
+ * capsule_wirebind_try_attach() (the original attach) and BINDSTEP
+ * (mama_word_use(), mama_forth_words.c -- re-verifies live on every USE
+ * of an identity-locked VM, per FABRIC-3.md §F.9 decision 1) so both
+ * call sites check the exact same thing the exact same way.
+ *
+ * No-op-and-fail (-1) if sig->cert_offset is 0 (no cert region -- a
+ * genesis-mode Zuse drive, or simply not a regular identity drive) or
+ * mama_vm has no installed Zuse cert yet.
+ *
+ * @param dev     Already-open block device to read the cert from.
+ * @param sig     Its already-checked homeblocks_sig_t.
+ * @param mama_vm Hera's own VM -- the trust root (zuse_cert_pubkey).
+ * @param out     Filled with the verified identity on success.
+ * @return 0 on success, -1 on any failure (read, verify, or precondition).
+ */
+int capsule_wirebind_verify_cert(struct blkio_dev *dev,
+                                  const homeblocks_sig_t *sig,
+                                  VM *mama_vm, VMIdentity *out);
+
 /**
  * capsule_wirebind_try_attach - Try to verify and bind a just-attached
  * regular (non-Zuse) identity drive.