Fix Artemis persist-read: reformat corrupted disk/artemis.img

Chases down the amd64/aarch64/riscv64 "FAIL: persist-read" that
capsules/artemis/init.4th's ART-READ-TEST self-test has been reporting
in every boot log in this repo's history.

Root cause: not a code bug. disk/artemis.img 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
begins -- already broken at the initial commit, carried over from the
pre-split monorepo. The FAIL was accurate: it correctly reported bad
data, not bad code.

Verified via a fresh disk/artemis-debug-roundtrip.img: format ->
self-test PASS -> write-test PASS -> reboot -> resume -> PASS:
persist-read, confirmed 3 times in a row. The write/read/persist code,
free map, block allocator, and C-level block subsystem cache/writeback
logic are all correct.

Fix: blanked disk/artemis.img and let a normal boot format + write-test
it fresh, then verified PASS: persist-read on amd64, aarch64, AND
riscv64 against the same reformatted image -- confirming the arch-neutral
on-disk format works cross-arch too (a boot on one architecture writes
data the other two can correctly read back).

disk/artemis-debug-roundtrip.img is kept as a regression fixture, already
in a known-good passing state -- a future break here is a real
regression, not fixture rot like artemis.img turned out to be.

disk/README.md: documented both images' state, and corrected a stale
claim that these images are managed via scripts/rundisk.sh -- that
script actually targets a separate, currently-unused disks/ (plural)
directory for the hosted VM's --disk-img= flag, not this kernel-QEMU
disk/ (singular) one.

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

disk/README.md

@@ -1,10 +1,33 @@
 # disk/
 
-QEMU disk images used for Artemis (block-storage VM) persistence testing,
+QEMU disk images used for Artemis (block-storage VM) persistence testing.
-created/managed via `scripts/rundisk.sh`.
+Mounted via `Makefile.starkernel`'s `ARTDISK` variable (default
+`disk/artemis.img`) as a `virtio-blk-pci` device on all three
+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.
+- `artemis.img` — standard Artemis persistence test disk. **Reformatted
-- `artemis-persist-test.img` — persistence round-trip test image.
+  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
+  begins (`git log` shows it already broken at the initial commit,
+  carried over from the pre-split monorepo). Chasing down the resulting
+  persistent `FAIL: persist-read` traced to the *data*, not the code —
+  the write→reboot→read round trip works correctly on a fresh image
+  (see `artemis-debug-roundtrip.img` below). Reformatted by blanking the
+  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).
+- `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.
+  Keep this in a passing state; if a future change breaks it, that's a
+  real regression, not a stale-fixture artifact like `artemis.img` was.
+- `artemis-persist-test.img` — persistence round-trip test image
+  (pre-existing; history/state not re-verified during the above
+  investigation).
 - `artemis-poison.img` — a separate test image (exact scenario not
   documented elsewhere in the repo as of this writing; name suggests an
   adversarial/corruption test, not confirmed).