pureboot: take the emitted loader HEX for --update-loader

The build emits an Intel HEX beside every loader image, but --update-loader
could not consume one: load_image() anchors every image at address zero, and
a loader HEX links at its base, so it decoded to a 32760-byte blob carrying
504 bytes of loader at the end. staging_content() then refused it as "loader
image is 32760 B, the slot holds 512" - an error naming neither the cause nor
the raw .bin the tool wanted instead.

Drop the blank below the base in the update path. The base comes from the
image's own info block rather than the device's, so an image built for
another target survives the slice intact and the preflight still reports it
as another target rather than failing to find an info block at all.

Verified on an ATmega328P: the full self-update flow driven straight from
pureboot_timeout-5s.hex, resident slot byte-for-byte against the image
afterwards, application preserved; both refusal paths unchanged.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

pureboot/README.md

@@ -124,7 +124,9 @@ the loader; an erase runs top-down for the same reason.
 
 `pureboot.py --update-loader new_pureboot.bin` replaces the resident loader
 with any pureboot build — a re-timed window, a newer protocol — using the
-loader itself as its own staging loader:
+loader itself as its own staging loader. The image is the loader's own 512
+bytes as a raw binary, or the Intel HEX the build emits beside it, which
+links the loader at its base inside an otherwise blank flash image:
 
 1. The staging slot `[base−512, base)` is saved to a host-side state file
    (on the 1 KB tiny13A that is the whole application, vectors included).