Rebuild disk/artemis.img fresh at 1 GiB, blank; preserve old 30 MiB image

Executes the drive-resize decision ratified in FABRIC-3.md §XXXV.6:
the prior 30 MiB image was too small for the block-backed per-ISA DoE
persistence design (§XXXV.2). Built a new blank 1 GiB image rather than
migrate the old one's top-of-device metadata fence -- re-minting Zuse
and the thumbdrive identities invalidates them either way, so skip the
migration entirely.

- disk/artemis.img: replaced with a fresh blank 1 GiB image (was 30 MiB)
- disk/artemis-30mb-pre-1gib-backup.img: the superseded 30 MiB image,
  preserved rather than deleted; disposal remains open (FABRIC-3.md §XXXV.7)
- disk/README.md: documented both images per this repo's own convention

Not yet formatted or re-minted -- that's a live-boot step, not done here.

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

disk/README.md

@@ -7,7 +7,27 @@ architectures' kernel QEMU boots — not `scripts/rundisk.sh`, which targets
 a separate, currently-unused `disks/` (plural) directory for the *hosted*
 VM's `--disk-img=` flag instead.
 
-- `artemis.img` — standard Artemis persistence test disk. **Reformatted
+- `artemis.img` — standard Artemis persistence test disk. **Rebuilt fresh at
+  1 GiB, 2026-09-17** (FABRIC-3.md §XXXV.6): the prior 30 MiB image was
+  three orders of magnitude too small for the block-backed per-ISA DoE
+  persistence design (§XXXV.2 — measured 516 MB for just 8 trials of raw
+  per-tick data against a 30 MiB device). Rather than migrate the existing
+  image's top-of-device system-metadata fence to new geometry (fence
+  addressing is relative to `total_devblocks`, so a resize alone would shift
+  every existing fence consumer onto the wrong physical bytes), Captain Bob
+  ratified building a brand-new blank image and re-minting Zuse + all
+  thumbdrive identities fresh against it, since re-minting invalidates the
+  prior identities regardless of whether a migration is attempted. Blank
+  (all zero) at creation, same as every other fresh-format fixture below —
+  not yet formatted or re-minted; that is a separate, later live-boot step.
+  The superseded 30 MiB image is preserved, not deleted, as
+  `artemis-30mb-pre-1gib-backup.img` (below).
+- `artemis-30mb-pre-1gib-backup.img` — the pre-2026-09-17 `artemis.img`
+  (30 MiB), preserved rather than deleted when `artemis.img` was rebuilt
+  fresh at 1 GiB (see above). Kept for reference / possible forensic
+  recovery of the prior Zuse/thumbdrive identity state; disposal is a
+  separate, still-open decision (FABRIC-3.md §XXXV.7), not made here.
+- (superseded, kept for history) `artemis.img` was previously **reformatted
   2026-08-02**: this image had been stuck in a corrupted state (valid
   `LithosAnanke` magic header, but data not matching what
   `ART-READ-TEST` expects) since before this repo's own git history
@@ -19,7 +39,8 @@ VM's `--disk-img=` flag instead.
   file and letting a normal boot format+write-test it; verified
   `PASS: persist-read` on amd64, aarch64, and riscv64 against the same
   image afterward (cross-arch resume, matching the arch-neutral on-disk
-  format `.claude/ARTEMIS.md` specifies).
+  format `.claude/ARTEMIS.md` specifies). This history now applies to
+  `artemis-30mb-pre-1gib-backup.img`, not to the current `artemis.img`.
 - `artemis-debug-roundtrip.img` — round-trip regression fixture created
   during that investigation. Known-good: format → self-test → write-test
   → reboot → resume → `PASS: persist-read`, confirmed 3 times in a row.