fix(blocks): a BAM flush reads and writes only the pages that hold the volume's bits (#155)

Accepted in full:
- amd64, aarch64, riscv64: PARITY:V4_POST tests=538 pass=538 fail=0,
  POST: PASSED, [zuse@Hera] ok> on a fresh data stick; dict_hash
  0xfec8c47cfc6f437f on the three
- the PC stick as built, loaded high: 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
- regressions: v3_keys, genesis on the three, stick_grow, midpull, hotplug

SAVE-BUFFERS on the 16 GiB stick: 5.1-6.1 s before, 1.1 s after; the BAM's
bytes the same (verdicts in logs/20261108-145611/verdicts/). FABRIC-3
XLVIII.14.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2

docs/fabric/FABRIC-3.md

@@ -6431,3 +6431,17 @@ Plan `2026-10-29-stick-5`, Task 2; `STICK.md` 5a (its 2 TiB cap amended to 256 G
   a regression -- written down here, since a lost virtio request is a fault of its own (v3 goes with
   #156).
 
+### 14. #155: a BAM flush moves only the pages that hold the volume (2026-11-08)
+
+- **Ruled** (Captain Bob, "Next up #155"): the change recommended in section 9.
+- **Built:** `bam_flush_to_disk()` and `bam_sync_from_disk()` (`v3/src/block_subsystem.c`, the block
+  layer v4 runs on) read and write only the BAM pages that hold a slot's bits -- its reserved bits
+  and one per user block (`bam_pages_used()`). The pages past them are never set, so the bytes on
+  disk are the same; v3's behaviour is unchanged.
+- **Tested first, seen to fail:** `bam_flush` (the PC stick grown to 16 GiB; three `SAVE-BUFFERS` of
+  an Artemis block, timed; the BAM hashed): 5.1, 5.6, 6.1 s against a limit of 2 s -- set after
+  seeing that baseline, written down so. After: 1.1 s each. The BAM's bytes the same either way.
+- **Accepted:** 538/538 and `POST: PASSED` on the three and the stick loaded high, `dict_hash
+  0xfec8c47cfc6f437f`, test-32 39 programs, 0 failures; regressions pass, `v3_keys` among them (v3
+  runs on the same code).
+