Phase 8 C (5/n): Zuse's cert wired to the fence -- first-boot mint works

Replaces the crashed NVRAM approach entirely. New
include/starkernel/zuse_cert_devblock.h: a standalone on-disk record
(magic + version + 32-byte seed + 32-byte pubkey + a real CRC-64/ISO
from day one, same discipline homeblocks_sig_t established) occupying
devblock_from_top=0 of the fence. Its own header, not inlined at the
boot call site, since the still-open MINT word will be a second
consumer of this exact format.

kernel_main.c's mint-or-load logic now reads the fence, installs an
existing valid cert, or mints fresh via virtio_rng+ed25519_keygen and
writes it. Runs right after virtio_rng_init(), before
capsule_birth_mama() -- unlike the crashed NVRAM attempt, raw block I/O
against Artemis's already-proven device has no boot-timing risk, so the
earlier "re-invoke ACL-ZUSE-BOOT after Mama birth" workaround is gone;
ACL.4th's self-activating ACL-ZUSE-BOOT sees a correct cert on its one
ordinary pass.

Verified independently across every real scenario, never trusting the
kernel's own report: fresh mint decodes correctly on disk with a CRC
confirmed by a from-scratch Python re-implementation of the algorithm;
a reboot without reformatting loads back byte-for-byte identical
seed/pubkey (genuinely "mint once, ever"); a pre-fence volume refuses
cleanly (no crash, no silent data loss, honest "not persistent"
reporting); the real, untouched disk/artemis.img exercises the same
graceful-refusal path identically on all three architectures.

Phase 8's core arc is now functionally complete: real entropy -> real
signing -> real anti-file block-native persistence -> a first-boot mint
that survives reboots. Still open: the ongoing MINT word for minting
additional regular users. Documented in FABRIC-3.md.

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

FABRIC-3.md

@@ -608,6 +608,50 @@ decisions get added here, not to `FABRIC-2.md`. Follow the same discipline `FABR
   these new accessors (the zone exists and works; nothing writes Zuse's cert into it yet), and
   the `MINT` word itself.
 
+  **Step 3 (Zuse's cert wired to the fence), done 2026-08-26 -- first-boot mint-then-load is
+  real, end to end.** New `include/starkernel/zuse_cert_devblock.h`: a small, standalone
+  on-disk record format (`zuse_cert_devblock_t` -- magic + version + 32-byte seed + 32-byte
+  pubkey + a real CRC-64/ISO from day one, same "real from day one" discipline
+  `homeblocks_sig_t` already established, since this gates a real security check) occupying
+  devblock_from_top=0 of the fence. Deliberately its own header, not inlined at the boot-time
+  call site: the still-open `MINT` word will be a second consumer of this exact format later.
+
+  `kernel_main.c`'s mint-or-load logic moved from the crashed NVRAM approach to this: read
+  devblock 0 of the fence, and if magic/version/CRC all check out, install the existing
+  cert; otherwise, if `virtio_rng` is ready, mint a fresh one (Phase A+B) and write it. Runs
+  right after `virtio_rng_init()`, well before `capsule_birth_mama()` -- unlike the crashed
+  NVRAM attempt, raw block I/O against Artemis's already-proven virtio-blk device has no
+  boot-timing risk at all, so the earlier "re-invoke `ACL-ZUSE-BOOT` after Mama birth"
+  workaround is no longer needed; `ACL.4th`/`zuse.4th`'s self-activating `ACL-ZUSE-BOOT` sees
+  a correctly-populated cert on its one, ordinary first pass.
+
+  **Verified live, independently, across every real scenario, never trusting the kernel's own
+  report:**
+  - **Fresh mint** (blank `disk/artemis-metafence-fresh.img`): boot logs `Zuse: minted, fuse
+    blown`; the on-disk record at the exact expected physical offset independently decodes to
+    magic bytes `b'ZUSE'`, version 1, a real 32-byte seed and pubkey, and a CRC that an
+    independent from-scratch Python re-implementation of the exact CRC-64/ISO algorithm
+    (table generation included, not just the check) confirms byte-for-byte.
+  - **Reload** (reboot the same now-minted image, no reformat): boot logs `Zuse: cert loaded
+    from block fence`; the on-disk seed and pubkey are byte-for-byte identical to the first
+    boot's -- genuinely "mint once, ever," not a silent re-mint.
+  - **Graceful refusal on a pre-fence volume** (`disk/artemis-metafence-test.img`,
+    `meta_fence_blocks=0`): `blk_meta_zone_read`/`write` both correctly refuse (no space to
+    read or write), so the kernel mints a cert for RAM/this-boot-only use and honestly reports
+    `Zuse: minted but fence write FAILED (not persistent)` -- no crash, no silent data loss,
+    no corruption of a device with no fence at all.
+  - **Real disk regression check:** the same graceful-refusal path exercised identically
+    against the real, untouched `disk/artemis.img` (which has no fence yet either) on all
+    three architectures -- clean boot, conservation intact, no panics, `disk/artemis.img`
+    itself reverted afterward (no committed churn).
+
+  **Phase 8's core arc is now functionally complete:** real entropy (Phase A) → real signing
+  (Phase B) → real, anti-file, block-native persistence (Phase C) → a working first-boot mint
+  that survives reboots. **Still open:** the ongoing `S" name" MINT` word for an authenticated
+  Zuse session to mint additional regular users (needs `zuse_cert_devblock_t`-format certs
+  signed by Zuse's own key, not just installed) -- the real remaining piece of the original
+  vision.
+
 ### From FABRIC-2.md §X, Milestone 5 — Console/VM key-match binding
 
 - [ ] Settle the still-open question: reuse `ACL-PIN`/`acl_allow` directly, or build a