fix: --flash never ran the brick guard, because it never read the fuses

check_walk_region() refuses an image writing into the span reset crosses to
reach the loader, and a plain --flash never ran it: the fuses were read for
--fuses and for --update-loader, so the tool read them to protect the loader
and never to protect the reset path. It cost an ssd1306 board - an application
grown through 0x7c00 on a 328P with hfuse 0xdc, reset landing mid-function,
an ICE the only way back.

The check now fetches its own input, so the operation that asks for no fuses
cannot skip it and neither can a direct API caller: pbdirty and pbmute call
op_flash() as a library and are guarded without a line changing in them.
Fuses that cannot be read are a refusal naming --assume-fuses and --force,
because unknown is not empty.

The rig had to stop lying first. The fuse read is an LPM diverted by BLBSET,
which simavr executes straight out of flash with no hook, so a fuse read
answered flash bytes and --fuses had been printing them on every chip. The
runner models the diversion at the SPMCSR write, -f states the profile - and
stores the register itself, since a registered handler replaces simavr's store
and would otherwise swallow every SPM command on the cores where nothing else
watches it.

pureboot.walk reproduces the brick: the unfixed tool writes 249 pages through
0x7c00 in silence, the fixed one refuses.

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

pureboot/README.md

@@ -587,8 +587,7 @@ one; a re-run on the resident's link finds nothing at all. The state file carrie
 the only bytes not recoverable from the device; losing it mid-update still
 completes the update, and the staging region comes back by reflashing the
 application. A boot-sectioned mega needs its fuses for the preflight — read
-from the device, or supplied with `--assume-fuses` where reading is impossible
-(simulators).
+from the device, or supplied with `--assume-fuses` where reading is impossible.
 
 ## Host tool
 
@@ -611,7 +610,11 @@ verify by read-back unless `--no-verify`, and a flash page that reads back
 wrong is rewritten up to three times before the run stops (see the fill above).
 `--verify-flash` only reports. Images are raw binary, or Intel HEX by
 extension. `--force` overrides the refusable safety checks — today, flashing
-application data into a mega's reset walk region.
+application data into a mega's reset walk region. That check reads the boot
+fuses itself rather than waiting to be handed them, because a plain `--flash`
+asks for none and is exactly the operation that must not skip it; fuses it
+cannot read leave the region unknown, and unknown is refused rather than
+assumed empty (`--assume-fuses` states them).
 
 `--autobaud` opens with the calibration pulse instead of the plain knock, for a
 loader built `SERIAL autobaud`; the rest of the session is identical, at
@@ -750,6 +753,13 @@ Per chip preset, `ctest` runs:
   a bare verify must see the corruption and the repairing verify must fix it in
   one rewrite. Hardware forbids the state here, but simavr dispatches SPM from
   anywhere, which is what makes the path constructible;
+- `pureboot.walk` (328P) — an application whose tail lands in the span reset
+  crosses to reach the loader, refused by a plain `--flash` and written only
+  under `--force`, with a lower image and an unprogrammed BOOTRST left alone.
+  The refusal is decided from a modeled fuse read: the diversion BLBSET arms
+  answers an LPM, which simavr executes straight out of flash with no hook, so
+  the runner lends those bytes the fuses for the cycles SELFPRGEN holds (`-f`
+  states them, unprogrammed elsewhere);
 - `pureboot.update` — the full `--update-loader` flow, then every power-fail
   phase: the device is killed mid-write, restarted from its flash dump, and a
   re-run must complete the update with the application intact;