Fix silent disk overwrite of unrecognized Artemis disks

The generic block subsystem (blk_format_or_load_disk) auto-reformatted
any disk lacking its own low-level 'STFR' header at attach time, before
Artemis's Forth-level BLANK/LithosAnanke/Unrecognized classification
ever ran -- so ART-HALT-UNRECOG's "Disk preserved" message was false.

Split detection from commit: an unrecognized/blank disk is now left
PROVISIONAL (geometry computed in memory only, all writes refused)
until explicitly confirmed via the new blk_subsys_confirm_format() /
BLK-CONFIRM-FORMAT primitive. Artemis calls it from ART-FORMAT and
ART-RESUME, never from ART-HALT-UNRECOG.

Verified on amd64/aarch64/riscv64: parity intact (identical dict_hash),
normal recognized-disk resume + persist-read unaffected, and a
regenerated disk/artemis-unrecognized-test.img (the old copy had itself
been silently corrupted by this exact bug) now stays byte-for-byte
identical across a halted boot on amd64 and riscv64.

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

disk/README.md

@@ -31,6 +31,30 @@ VM's `--disk-img=` flag instead.
 - `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).
+- `artemis-unrecognized-test.img` — exercises `ART-HALT-UNRECOG`
+  (`.claude/ARTEMIS.md` acceptance criterion #6). **Regenerated
+  2026-08-02**: the previous copy of this file had itself been silently
+  reformatted by a since-fixed bug in the *generic* block subsystem
+  (`src/block_subsystem.c`) — it carried a valid low-level `'STFR'`/v2
+  header despite being meant to represent foreign disk content, direct
+  forensic evidence of the bug described in `.claude/ARTEMIS.md`'s
+  Build Status item 6. Regenerated as 30MB of a repeating
+  `POISON-UNRECOGNIZED-DISK-TEST-FIXTURE--NOT-BLANK-NOT-STFR-NOT-ARTEMIS--`
+  ASCII pattern — deliberately neither blank, nor the block subsystem's
+  own `'STFR'` magic, nor Artemis's `"ARTEMIS\0"` marker. Verified on
+  amd64 and riscv64 post-fix: boot correctly halts
+  (`ARTEMIS HALT: unrecognized disk content`) and the file's sha256 is
+  now byte-for-byte identical before and after boot. Keep this fixture
+  in this poisoned state — if a future change makes its sha256 change
+  across a boot, that is exactly the regression this fixture exists to
+  catch.
+
+Note on incidental header churn: `artemis.img` picks up a few changed
+header bytes on every ordinary boot even though no user data changes —
+`blk_subsys_attach_device()` always records a fresh `mounted_time` on a
+successfully recognized disk, which gets flushed at shutdown. This is
+expected bookkeeping, not a bug; revert it before committing rather than
+carrying timestamp noise in git history.
 
 These are regenerable QEMU raw disk images, not source — see
 `.claude/ARTEMIS.md` for the storage model they exercise.