Baked container images load only on the wizard path — keep-reinstalls and A/B updates run stale containers forever

[VijitSingh97]

Found live: a keep-reinstall to RC19 booted the RC19 OS (BUILD_COMMIT correct) while the
dashboard container kept running the RC14-era image. The image tag (:v1.14.1) is constant
across RCs, podman's store lives on the preserved /data, and the sha-keyed loader for the baked
archive lives in the FIRSTBOOT path — which keep-reinstalls (and A/B updates) skip entirely.
New slot, stale containers: #790's exact pattern one layer up. The visible symptom was a
dashboard hung at "Connecting…" with every shipped fix mysteriously absent.

This breaks the A/B update story (M7-M9): an OS update that carries a new dashboard would keep
running the old one, indefinitely, on every provisioned machine. Release blocker.

Fix direction (the derived-layer rule again): archive loading belongs in the BOOT path, not the
wizard. pithead-boot (or render) compares the baked archive's sha against the recorded one and
podman-loads on mismatch, then compose up recreates on the image-id change — every boot, both
paths, no wizard involvement. The recorded sha lives beside the store it describes. The manual
recovery that worked live: podman load -i /opt/pithead/images/dashboard.tar.gz, rm the
container, pithead up.

Coverage: the update phase must assert a marker from the NEW dashboard image is served after an
A/B update (not merely that containers run); the install phase's keep leg should assert the
dashboard image id changed after a keep-reinstall from a newer stick.

[VijitSingh97]

Fixed on feat/phase2-bakery-image: pithead-boot sha-checks every baked archive each boot and loads on mismatch before render/up, so keep-reinstalls and A/B updates both converge the containers. Verified live on the bench (manual equivalent) — gates with the next RC20 cycle, which must also add the update-phase image-id assertion this issue names.

[VijitSingh97]

Follow-through in #807 (on top of 838a18d, which put the loader loop into pithead-boot):

What moved where

• The loader is now ONE function, load_baked_images in the pithead CLI, exposed as pithead load-images. pithead-boot runs it before render/up on every provisioned boot; the first-boot wizard calls the same function (naming its image so a wiped store forces a load past a stale digest record). The wizard's separate .wizard-image-sha loop is deleted — both paths share the per-archive records at /data/pithead/data/.loaded-<archive>.sha, beside the store they describe.

What the next KVM battery will now assert (it has NOT run — needs the bench):

• update phase: harness builds stamp the marker into the dashboard image at a served path; after the committed A/B update the page must carry the NEW image's marker — running containers alone no longer pass.
• install phase, keep leg: keep-reinstall now comes from a newer stick over a /data pre-planted with the old dashboard image and its digest record; the image ID must change and the served page must come from the newer image.
• provision phase: the digest records are dropped with the corrupted Caddyfile before the unaided reboot and must come back — pinning pithead-boot itself as the loader on a provisioned machine.

Tier 1 covers the pure logic (digest-decides-load, skip, reload, forced load, no record on failure) against a stub engine: tests/stack/run.sh 1807/0 locally, make lint green.