Verify the release bundle hash before extracting (both images)

[jsokol]

Description

Both production images built by streaming curl … | tar xz with no integrity check on the release bundle. This adds a download → verify → extract step: a new common/download_and_verify_bundle.sh downloads the bundle, resolves the published bundle_sha256 (md5 fallback, fail-closed if neither) from updates.simplerisk.com/releases.xml, verifies, then extracts. Both generate_dockerfile.sh release variants now COPY + run the script instead of streaming; the full image keeps its trailing SQL download in the same RUN. The testing variant (which COPYs local code, no download) is untouched. Both committed Dockerfiles are regenerated.

Defense-in-depth: the bundle (S3 public/bundles) and its hash (served updates feed) are independently stored, so a swapped S3 object fails the build instead of being baked into a published image. The hash is resolved at build time because generate_dockerfile.sh runs at version-bump time, before the new release's feed entry exists.

No runtime/entrypoint change — the resulting image filesystem is identical (same bundle), so EKS and every consumer run it exactly as before. generate_dockerfile.sh also gains a YYYYMMDD-NNN|testing version-format guard.

Design: code-development docs/superpowers/specs/2026-06-07-docker-bundle-verification-design.md.

Testing

• Script standalone: positive (real 20260519-001 bundle → Bundle sha256 verified (7d7fb2…) → extracted) and negative (byte-corrupted bundle → sha256 mismatch, exit 1).
• Minimal image: full docker build shows Bundle sha256 verified + Extracted bundle to /var/www in the downloader stage; boot smoke (mysql + container) reaches Setup has been applied successfully! and returns HTTP 200 — runtime unchanged.
• Full image: docker build shows the verify step + the preserved SQL download, build completes.
• container-validation.yml runs the full release build of all four images on this PR.

🤖 Generated with Claude Code