Phase 8 C (3/n): top-of-device metadata fence, step 1 (field round-trip)

Corrected substrate: this OS is anti-POSIX, anti-file by design -- the
prior "dedicated system-identity disk" framing was wrong vocabulary,
caught before any code was written (saved as
feedback_no_files_anti_posix.md). The real primitives are
content-addressed capsules and raw LBN blocks, never a filesystem.

Design (agreed on request): a growable metadata fence at the TOP of a
device's block space, mirroring block_subsystem.c's existing bottom BAM
reservation from the opposite end -- the two grow toward each other,
never colliding, same shape as a stack/heap. Starts at
BLK_META_FENCE_INIT (128 blocks), explicitly never RAM-backed. Reuses
Artemis's already-attached, already-proven virtio-blk device -- no new
device. Rejected reusing BAM's own reserved zone directly: those blocks
are fully claimed by BAM bookkeeping, not free space.

Step 1 only: new meta_fence_blocks field in blk_volume_meta_t, appended
after reloc_devblocks and carved from _pad[] -- identical graceful-
default technique reloc_devblocks already established (a pre-existing
volume reads it back as 0, not a format break). Added a compile-time
_Static_assert on the struct's total size, same discipline
homeblocks_sig.h uses -- caught a real bug immediately: the hand-summed
_pad[] formula was off by 4 bytes (a compiler alignment gap the manual
count missed), found via offsetof() rather than re-deriving by hand.

Worked against disposable clones throughout, never the real
disk/artemis.img (ARTDISK is ?=-overridable) -- artemis-metafence-fresh.img
(blank, fresh-format path) and artemis-metafence-test.img (copy of the
pre-existing artemis.img, graceful-default-on-reload path), kept as
regression fixtures matching disk/README.md's existing convention.
Verified independently via direct byte reads of the disk image, not the
kernel's own log output (log_message(LOG_INFO,...) doesn't reach serial
in this build -- unrelated pre-existing gap): fresh format writes 128 at
header offset 184, a reboot without reformatting preserves it, the old
pre-fence image reads back 0. Full 3-arch acceptance boot against the
real, untouched disk/artemis.img also clean.

Allocator (user_blocks math) and zone read/write accessors both still
open -- next steps, documented in FABRIC-3.md.

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

disk/README.md

@@ -83,6 +83,25 @@ carrying timestamp noise in git history.
   `BLK-CONFIRM-FORMAT`-committed in the repo copy — commit that step live if
   reusing this fixture for further reloc-table testing.
 
+- `artemis-metafence-fresh.img` — 30MB raw image, blank at creation,
+  added 2026-08-26 for the top-of-device system-metadata fence
+  (`meta_fence_blocks` in `blk_volume_meta_t`, FABRIC-3.md Phase 8 §C).
+  Same reasoning as `artemis-reloc-test.img` above: the fence is only
+  initialized to `BLK_META_FENCE_INIT` (128) by
+  `blk_compute_fresh_geometry()` on a fresh format, so a genuinely blank
+  volume was needed to exercise that path. Verified round-trip: fresh
+  format writes 128 (confirmed via direct byte read at header offset 184,
+  independent of kernel self-report), a second boot without reformatting
+  reads it back unchanged. Keep in its formatted (`meta_fence_blocks=128`)
+  state — a future change that resets or corrupts this on reload is a
+  real regression.
+- `artemis-metafence-test.img` — 30MB raw image, a direct copy of the
+  pre-existing (pre-fence) `artemis.img`, added 2026-08-26 alongside the
+  fixture above to verify the *other* direction: an old volume that
+  predates `meta_fence_blocks` correctly reads it back as 0 (graceful
+  default via zeroed former padding, not corruption) rather than crashing
+  or misreading adjacent fields.
+
 - `zuse.img` — 64MB raw image simulating the physical Zuse superuser
   thumbdrive for QEMU testing (FABRIC-3.md, Phase 8: `zuse.img` "bleach"
   mechanism, added 2026-08-26). **64MB is only this fixture's size, not a