Execute FABRIC-3.md §XXXV.6: format new artemis.img, re-mint all 9 identities live

Boots amd64 with Zuse's bleached thumbdrive, confirms live: fresh 1 GiB
disk/artemis.img formats ("Artemis: blank disk -- formatting"), Zuse
genesis-mints onto it ("Zuse: genesis minted onto attached thumbdrive",
root CA written to the new fence's devblock 0), session authenticates
(zuse@Hera ok>). With Zuse live, mints the other 8 identities (bob, 00-06)
one at a time via QMP-driven xHCI hotplug + MINT at the console, each
confirmed by its own "MINT: identity minted" log line before detaching
and moving to the next. Clean BYE shutdown, zero leaked qemu/socat
processes, all 9 images verified nonzero.

Root cause confirmed live before executing: Zuse's genesis marker lives
on artemis.img's own fence (devblock_from_top=0), not on her thumbdrive
-- with the marker gone, her old drive could not have re-authenticated
regardless of its own content, confirming re-mint was genuinely required.

FABRIC-3.md §XXXV.7/.8, disk/README.md updated with the full account.
Serial log preserved: logs/20260917-114652/amd64/.

Still open: the block-backed DoE persistence writer itself is unbuilt
(design only); ZUSE-ELIGIBILITY-ADD (elevation eligibility, narrower
than baseline auth) not re-populated for any of the 8; old 30 MiB
artemis.img backup disposal undecided.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-3.md

@@ -5473,7 +5473,54 @@ device it was minted on.
 - The **old 30 MiB `disk/artemis.img`** is left alone / superseded, not deleted here -- disposal
   of the old file is a separate, later call once the new one is confirmed live and correct.
 
-### XXXV.7 -- Genuinely open, not decided here
+### XXXV.7 -- §XXXV.6 EXECUTED live: fresh `artemis.img` formatted, all 9 identities re-minted,
+verified end to end (2026-09-17)
+
+Before executing, confirmed the root cause that made re-mint (not just re-registration)
+mandatory, not merely likely: `capsule_zuse_boot.c`'s `genesis_marker_read()` reads Zuse's
+`zuse_pubkey` root-CA marker from **Artemis's own disk fence** (`devblock_from_top=0`), not from
+her thumbdrive -- her thumbdrive only carries her seed/cert, checked *against* that marker.
+With the marker gone (fresh `artemis.img`), `capsule_zuse_boot_try_attach()`'s own logic
+silently no-ops for a non-blank, already-minted drive (the `!have_marker` branch only proceeds
+if the attaching drive is *also* blank) -- her old thumbdrive genuinely could not have
+re-authenticated against the new disk, confirming the user's original instinct
+("reminting will invalidate the existing identities too") was correct, not merely cautious.
+Also confirmed `capsule_mint_identity()` refuses to write over an already-recognized drive
+(`MINT_ERR_ALREADY_MINTED`), so bleaching all 9 thumbdrive images to blank first was mandatory,
+not optional, before any of them could be re-minted.
+
+**Executed, in order:**
+1. Bleached all 9 `disk/thumbdrives/*.img` (zuse, bob, 00-06) to all-zero, 64 MiB each,
+   verified zero nonzero bytes and size intact. Committed (`e56974e`).
+2. Booted amd64 (`make -f Makefile.starkernel ARCH=amd64 qemu QEMU_DISPLAY=none`, orchestrated
+   headless via a bash+socat+QMP driver script, not `-display gtk` this time since this session
+   has no visual terminal) with Zuse's now-blank drive attached at launch (the Makefile's own
+   default `ZUSEDISK`). Confirmed live in the serial log: `Artemis: blank disk -- formatting`
+   (fresh 1 GiB image formatted), `Zuse: genesis minted onto attached thumbdrive` (root CA
+   written fresh to the new fence), prompt reached `zuse@Hera ok>` (session authenticated).
+3. With Zuse authenticated, minted the other 8 identities one at a time against the **same
+   still-running instance** -- hot-attached each blanked thumbdrive over QMP
+   (`human-monitor-command` wrapping `drive_add`/`device_add` against `xhci0.0`, mirroring the
+   2026-09-06 session's HMP-not-QMP-JSON approach but reached through the QMP socket the current
+   `Makefile.starkernel` actually wires up, since no separate HMP monitor socket exists in the
+   current target), minted via the live console (`MINT-NUM`, a thin `MINT` wrapper defined
+   at the console for the 6 numeric identities exactly as in the original 2026-09-06 procedure;
+   full `full_name`/`username`/`email` `MINT` call for `bob`), then hot-detached
+   (`device_del`/`drive_del`) before the next. All 9 `MINT: identity minted` confirmations
+   present in the log (the 9th being the "00" identity, validated first as a single-device
+   dry run before looping the remaining 7 -- caught and fixed a false-negative bug in this
+   session's own verification helper, a classic `grep -c ... || echo 0` double-output bug, before
+   trusting the result on the other 7).
+4. Clean `BYE` shutdown, confirmed zero leaked `qemu-system-x86_64`/`socat` processes afterward.
+   All 9 thumbdrive images confirmed nonzero in their first 6 devblocks (same verification
+   convention as the original mint); `disk/artemis.img` confirmed no longer blank
+   (27,618 nonzero bytes of real fence/format data). Full log preserved:
+   `logs/20260917-114652/amd64/qemu-amd64-20260917-114652.log`.
+
+Committed and pushed (image/log commit follows this one). `disk/README.md` updated with the
+same account.
+
+### XXXV.8 -- Genuinely open, not decided here
 
 - **Exact v2 decimation factor**, if/when v2 is built at all (§XXXV.4).
 - Whether `THRU`'s own line-swallowing defect (§XXXIV.1, still un-root-caused at the C level) gets
@@ -5482,9 +5529,13 @@ device it was minted on.
   applies either way.
 - Disposal of the two stale partial amd64 runs' data (§XXXIV.5's own still-open item) is unrelated
   to this pivot and remains undecided.
-- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 1 GiB image is
-  confirmed live (§XXXV.6).
-- **Nothing built yet** -- this section (including §XXXV.6's ratified drive-resize decision) is
-  design/decision only, no capsule/C code, no new disk image, and no re-mint actually performed
-  or committed for the drive resize, the persistence region, or the N=2 campaign shape.
+- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived now that the new 1 GiB image is
+  confirmed live and re-minted (§XXXV.7).
+- The block-backed DoE persistence writer itself (§XXXV.3/§XXXV.4) is still design-only -- no
+  capsule/C code written for it. Only the drive-resize/re-mint prerequisite (§XXXV.6) is done.
+- The `ZUSE-ELIGIBILITY-ADD` elevation-eligibility list (narrower than baseline identity auth --
+  only gates the `ELEVATE` flow in `capsules/zuse-eligibility.4th`, confirmed by reading its only
+  call site) was **not** re-populated for any of the 8 re-minted identities during this pass --
+  their baseline identity/auth works (confirmed live), but elevation eligibility, if any of them
+  had it before, was not restored. Left open; re-add via `ZUSE-ELIGIBILITY-ADD` later if needed.