Single-block relocation: RELOCATE-BLOCK, resolve_lbn(), persisted exception table

Implements the full design from the prior commit in one pass. resolve_lbn()
is the single choke point threaded through the ten public LBN-consuming
entry points (blk_get_buffer, blk_update, blk_flush, blk_is_allocated,
blk_mark_allocated, blk_mark_free, blk_is_valid, blk_get_meta, blk_set_meta,
plus blk_get_empty_buffer covered via delegation) -- an LBN->LBN redirect,
not a new storage allocator, since the LBN space is already unified across
every attached blkio_dev backend. VM window cache staleness across a
relocation reuses the existing blk_vm_check_epoch() mechanism from
Milestone 2h's hot-detach fix for free -- g.epoch bumps on relocation too.

Persistence lands in the same pass: two new uint32_t fields
(reloc_start/reloc_devblocks) appended after hdr_crc in blk_volume_meta_t,
carved from existing padding without moving any earlier field's byte
offset -- an old formatted volume's zeroed padding reads back as
reloc_devblocks=0 ("no reloc capacity"), gracefully, not a format-breaking
change. compute_totals_from_B() generalized to account for the new
reserved region. reloc_flush_to_disk()/reloc_load_from_disk() mirror the
BAM I/O functions' own absolute-devblock-addressing shape; the persisted
copy's owner is first_disk_slot() (already existed, already used for this
exact "which device is canonical" question by blk_get_volume_meta()).
blk_subsys_relocate_block() is a mechanical primitive only -- copies
content (staged through a local buffer, since obtaining the target's
blk_get_buffer() result can evict and invalidate the source's cache
pointer if they share a device), frees the source BAM entry, appends the
exception entry, bumps the epoch, flushes to disk. RELOCATE-BLOCK exposes
it to FORTH, no policy of its own (ACL's job, per this session's direction).

A first live-test attempt gave a false negative against disk/artemis.img
(predates reloc capacity, so relocation only ever existed in memory that
boot) -- traced to the test's own setup before being mistaken for a bug,
then re-verified correctly against a fresh volume (new fixture,
disk/artemis-reloc-test.img): relocated a RAMDRIVE block to the fresh
disk, confirmed live resolution through the redirect, then confirmed both
the redirect and the relocated content survived an abrupt QEMU kill and
full reboot. Also fixed three lingering "glibc" doc-comment
misattributions from Milestone 2h (the actual allocator is this kernel's
own kmalloc) that survived an earlier FABRIC-2.md-only correction. All
three architectures re-verified clean.

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

disk/README.md

@@ -71,6 +71,17 @@ carrying timestamp noise in git history.
   silently replaying the old device's cached (all-zero) content, which is
   exactly the class of bug a same-LBN-range device swap can cause if the
   VM block window cache (`vm->blk_vm_cbuf[]`) isn't re-validated on a hit.
+- `artemis-reloc-test.img` — 64MB raw image, added 2026-08-25 for single-block
+  relocation (`RELOCATE-BLOCK`) persistence verification. Blank at creation;
+  a genuinely *fresh* volume was required (not `artemis.img`) because
+  relocation-table capacity (`reloc_start`/`reloc_devblocks` in
+  `blk_volume_meta_t`) is only reserved by `blk_compute_fresh_geometry()` on
+  a fresh format — `artemis.img` predates the feature and correctly reads
+  back `reloc_devblocks=0` from what was previously unused header padding.
+  Attach via `make -f Makefile.starkernel ARTDISK=disk/artemis-reloc-test.img
+  ...` (the Makefile's `ARTDISK` var is `?=`-overridable). Not yet
+  `BLK-CONFIRM-FORMAT`-committed in the repo copy — commit that step live if
+  reusing this fixture for further reloc-table testing.
 
 **Convention, standing as of 2026-08-22: every virtual disk/thumb-drive image
 used for testing — Artemis persistence disks above, and USB Mass Storage