Four bugs found live verifying the 8 identity thumbdrives (FABRIC-3.md §IX)

All found by actually running the identity workflow §VII/§VIII made
possible, not by code review:

1. Zuse/WIREBIND cross-contamination on detach: capsule_zuse_boot_logout()
   and capsule_wirebind_unclean_detach() both had no device parameter, so
   an unrelated device detaching (while the real owner's own stayed
   attached) incorrectly tore down the wrong session. Both now compare
   the departing device against their own tracked one, mirroring
   capsule_wirebind.c's pre-existing g_wirebind_attached_dev precedent.

2. Dictionary-entry memory leak: vm_create_word()'s sf_malloc()'d
   DictEntry (plus a second per-entry allocation for transition_metrics)
   was never freed by vm_cleanup(), in both the hosted and kernel
   implementations. Caused a real kernel PANIC after 8-9 repeated VM
   birth/kill cycles in one boot. Fixed by walking vm->latest in both.

3. sf_malloc/sf_free (alloc_kernel.c) was a 4MB bump arena with a
   deliberate no-op free, sized on "VM born once, never killed" -- fix #2
   alone didn't stop the panic because free() itself discarded the
   pointer regardless. Given a real free list (first-fit reuse).

4. Headless-console gate didn't re-engage after a mid-boot logout: the
   original fix (sk_console_mark_login(), one-way sticky) only gated the
   first login of the boot. Replaced with a live check
   (sk_console_identity_present()) re-evaluated continuously, including
   inside sk_console_readline()'s own blocking idle loop -- the console
   is normally sitting blocked there when a hot-unplug logout happens, so
   checking only at the top of the REPL loop wasn't enough.

Also: MINT now verifies its own write (verify_mint(), capsule_mint.c) by
reading back through the same check a real attach performs, rather than
trusting blkio_write()'s BLK_OK alone -- logged via log_message(), not
console_println(), per direct instruction.

Verified live, amd64: the full 8-identity repeated attach/detach cycle
that previously panicked at the same point every time now completes
clean, and a full serial-log sweep found zero bare unauthenticated
prompts anywhere in the run. Three-arch clean-qemu acceptance passed.

Still open, not fixed here: a 3+-simultaneous-device USB enumeration
failure found in a separate live test, not yet root-caused.

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

src/starkernel/capsule/capsule_wirebind.c

@@ -204,9 +204,12 @@ void capsule_wirebind_try_attach(struct blkio_dev *dev,
     memcpy(g_wirebind_attached_username, username, sizeof(g_wirebind_attached_username));
 
     /* Decided 2026-09-05: no console for the running system unless a
-     * thumbdrive is present -- this successful console+user VM birth is
-     * exactly that login. See repl.h's own doc comment. */
-    sk_console_mark_login();
+     * thumbdrive is present. Revised 2026-09-06: this used to call
+     * sk_console_mark_login() here (a one-way sticky flag) -- the gate is
+     * now a live check (sk_console_identity_present(), repl.c) driven
+     * directly by g_wirebind_attached_username being set above, re-checked
+     * continuously by sk_repl_run()'s own main loop rather than a one-shot
+     * signal at login time. Nothing to call here anymore. */
 
     /* Register the pairing in the console's own routing table, index 3
      * -- the fixed convention sk_repl_dispatch_line() (repl.c) uses. */
@@ -264,7 +267,18 @@ int capsule_wirebind_eject(void) {
     return 0;
 }
 
-void capsule_wirebind_unclean_detach(void) {
+void capsule_wirebind_unclean_detach(struct blkio_dev *dev) {
+    /* FABRIC-3.md §VII follow-on, 2026-09-06: same defect class as
+     * capsule_zuse_boot_logout()'s own fix, found in the same live
+     * verification session -- this used to take no device parameter at
+     * all, so an unrelated device detaching (Zuse's own drive, or general-
+     * purpose USB use) while a WIREBIND user stayed attached would
+     * incorrectly tear down that user's session too. The single-USB-
+     * device constraint this was written under never let a *different*
+     * device be the one detaching while a WIREBIND user's own stayed live
+     * -- stale now that genuine multi-device attach exists. */
+    if (dev != g_wirebind_attached_dev) return;
+
     VMRegistryEntry entry;
     if (wirebind_resolve_attached(&entry) != 0) return;