fix(os): one baked-image loader for both boot owners; the battery now proves containers refresh

[VijitSingh97]

Closes #798.

Commit 838a18d put a loader loop into pithead-boot; this PR finishes the job the issue asks for: one shared mechanism, and a battery that can actually catch the regression.

One loader, both boot owners

• load_baked_images now lives in the pithead CLI (exposed as plumbing: pithead load-images). Digest-keyed: sha256 of each /opt/pithead/images archive against a record at /data/pithead/data/.loaded-<archive>.sha — beside the store it describes, same path the committed boot loop already used. Load on mismatch, record only on success (a failed load must retry next boot, not skip).
• pithead-boot calls ./pithead load-images before render/up — every provisioned boot, so keep-reinstalls and A/B updates converge without wizard involvement.
• The wizard's duplicate loop (.wizard-image-sha stamp) is gone; firstboot_wizard calls the same function, naming the image it needs so a wiped store forces a load past a stale record (the one behavior the wizard had that the boot loop lacked). The old stamp file is simply orphaned; first boot on this build reloads once and starts the per-archive records.

What the next KVM battery will assert (NOT run here — see below)

• os/build-image.sh: harness builds (PITHEAD_TEST_MARKER set) stamp the marker into the dashboard image at a served path (/static/os-test-marker.txt), as an extra layer. Release builds are unchanged. This makes v1/v2 dashboard archives actually differ and lets the battery see WHICH image answers.
• update phase: baseline "v1 image serves its marker" before any update; after the committed update, the served page must carry the v2 marker — "containers run" no longer passes for stale containers.
• install phase, keep leg: now reinstalls from a newer stick (v2 build) over a /data pre-planted with the old dashboard image and its digest record (via podman --root from the installer VM — the exact machine state that hit the bench). Asserts the dashboard image ID changed and the served page carries the newer marker.
• provision phase: the digest records are dropped alongside the corrupted Caddyfile before the unaided reboot and must come back — that pins pithead-boot itself (not the wizard) running the loader on a provisioned machine.

Tier 1

tests/stack/run.sh replaces the old sha-modeling block with tests of the real function against a stub engine: first-boot load, unchanged-archive skip, changed-archive reload, missing-required-image force, and no-record-on-failed-load.

Docs

docs/dev/appliance-wizard.md boot contract is now four steps (images are derived, converged every boot); docs/dev/appliance-release.md battery table updated with the new assertions and counts.

Verified locally

• make lint green (includes shellcheck/shfmt, docs voice, operator strings — the new console/help strings carry no issue numbers). The branch's make lint was red on an unrelated import sort in test_data_service.py; fixed in its own commit.
• tests/stack/run.sh: 1807 passed, 0 failed (includes the 6 new loader assertions).
• build/dashboard pytest for the touched test file: all pass.
• CLI smoke: pithead load-images with a stub podman — one load, digest recorded, second run a silent no-op, option rejection works.

Not verified

The KVM battery (tests/os/run.sh) has not run — it needs the bench. The new update/install/provision assertions are untested against a live VM; the next battery run exercises them, and the keep leg's podman --root plant is the piece most worth watching on that run.

🤖 Generated with Claude Code