Add disk/zuse.img + bleach_zuse_img.sh: first-boot mint testing (Phase 8)

Resolves the acl_pinned punch-list item's open question: credential
data (ZUSE-CERT-LO/HI, ACL-CA-KEY-LO/HI) are CONSTANT words, i.e. real
DictEntrys, and acl_pinned's enforcement (vm_create_word()'s
unconditional shadow-refusal for any pinned name) already covers this
generally -- no new flag needed, zuse.4th's ACL-ZUSE-BOOT already pins
both cert constants today.

That investigation surfaced a real gap: ACL-ZUSE-BOOT pins the cert
constants unconditionally on every boot, before any legitimate mint
could ever run, permanently locking in the 0 placeholder on the very
first boot. This directly shaped Captain Bob's next design pass: a
dedicated zuse.img test thumbdrive, "bleachable" back to pristine
state for repeated first-boot testing; a one-time mint-then-pin flow
(fixing the gap above); a separate ongoing S" name" MINT word for
minting additional regular users; and an explicitly-deferred Zuse
recovery path question.

This commit is the first piece: disk/zuse.img (64MB blank, matching
the existing USB-fixture convention) + scripts/bleach_zuse_img.sh
(idempotent reset). Verified live via QMP hotplug -- reads back as
HOMEBLOCKS_SIG_BLANK, correctly simulating a genuine first boot.
Deliberately flat/raw, not GPT-partitioned, matching
homeblocks_sig_check()'s current sig_start_fblock=0 assumption; both
move to a real GPT-relative offset together once a parser exists. No
kernel code touched -- host-side test tooling only, no 3-arch
acceptance boot needed.

Still open: the mint-then-pin boot fix, the MINT word, Zuse recovery.

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

FABRIC-3.md

@@ -265,11 +265,44 @@ decisions get added here, not to `FABRIC-2.md`. Follow the same discipline `FABR
   Conservation intact, no panic. Clean zero-warning compile and clean boot on all three
   architectures.
 
-- [ ] Extend `acl_pinned`'s one-way-ratchet mechanism (already exists, already proven, just
-  needs applying) to gate zuse credential minting specifically — confirm whether this
-  literally reuses the existing `acl_pinned` bit on some relevant `DictEntry`, or needs its
-  own analogous one-way flag on the credential data itself (the credential isn't a dictionary
-  word, so the existing bit may not directly apply — open question, not yet resolved).
+- [x] **Resolved (2026-08-26): reuse `acl_pinned` directly, no new flag needed.** The open
+  question assumed credential data "isn't a dictionary word" — but the design already chosen
+  for it (`ZUSE-CERT-LO`/`HI`, `ACL-CA-KEY-LO`/`HI`) are `CONSTANT` words, i.e. real
+  `DictEntry`s. `acl_pinned`'s enforcement is more general than assumed: `vm_create_word()`
+  (`dictionary_management.c:394-404`) — the single choke point every word-defining construct
+  goes through — unconditionally refuses to let *anything* shadow a pinned name ("Pin is
+  permanent: no word may shadow a pinned entry — ever, by anyone"), a real general
+  redefinition guard, not just an ACL-mode-change lock. `zuse.4th`'s `ACL-ZUSE-BOOT` already
+  pins both cert constants today — the mechanism is already wired for this.
+
+  **Real gap surfaced along the way, not yet fixed:** `ACL-ZUSE-BOOT` self-activates and pins
+  `ZUSE-CERT-LO`/`HI` unconditionally on *every* boot — before any legitimate minting step
+  could ever run, permanently locking in the `0` placeholder on the very first boot. The boot
+  sequence needs to distinguish "already minted, pin it" from "not yet minted, don't pin yet"
+  before minting can work at all.
+
+  **This directly shaped the next design pass (2026-08-26, Captain Bob):** a dedicated
+  `disk/zuse.img` QEMU test thumbdrive, "bleachable" back to pristine/unminted state for
+  repeated first-boot testing; a one-time first-boot mint-Zuse flow (mint → write real cert →
+  blow the fuse → *then* pin, resolving the gap above); a separate, ongoing `S" name" MINT`
+  word for an authenticated Zuse session to mint additional regular users; and a Zuse recovery
+  path, explicitly flagged as unresolved and risky if rushed — not to be designed casually,
+  since the earlier "no software recovery, mint a new one" rule existed specifically to close
+  a hole a careless recovery path could reopen.
+
+  **First piece implemented (2026-08-26): the `zuse.img` bleach mechanism.**
+  `disk/zuse.img` (64MB, blank, matching the existing USB-fixture convention exactly — see
+  `disk/README.md`) + `scripts/bleach_zuse_img.sh` (idempotent reset back to blank). Verified
+  live: hot-attached via QMP (same method as the warn-and-refuse verification above) — reads
+  back as `HOMEBLOCKS_SIG_BLANK` (`xhci: USB drive not recognized (blank or foreign media)`),
+  correctly simulating a genuine first boot. Deliberately flat/raw, not GPT-partitioned,
+  matching `homeblocks_sig_check()`'s current `sig_start_fblock=0` call site — both move to a
+  real GPT-partition-relative offset together once a parser exists, not attempted here. No
+  kernel code touched this step (host-side test tooling only), so no 3-arch acceptance boot
+  needed — single live amd64 QMP-hotplug confirmation is the right verification tier.
+
+  **Still open, not attempted:** the mint-then-pin boot-sequence fix itself, the `MINT` word,
+  and the Zuse recovery path.
 
 ### From FABRIC-2.md §X, Milestone 5 — Console/VM key-match binding