Pin server image base by digest

[den-sq]

Summary

• pin the Poetry Python base in both server Dockerfiles to its immutable manifest digest
• retain the readable upstream tag alongside the digest
• document the deliberate, paired tag-and-digest upgrade procedure

Closes #128

Validation

• docker buildx build --check --file python/Dockerfile python
• docker buildx build --check --file python/Dockerfile-prod python
• poetry run pytest (169 passed)
• npx --no-install prettier --check documentation/docs/development/registry-server-images.md
• git diff --check

Shared-basis audit

• Inspected the two server Dockerfiles, the server-image workflow, and the existing registry server-image lifecycle documentation.
• Reused documentation/docs/development/registry-server-images.md as the canonical base-image bump procedure; no parallel lifecycle mechanism was added.
• Load-bearing decision: resolve and pin the existing human-readable tag to Docker Hub manifest digest sha256:4e091da0d71700b404a2844ac3bbd4aaa3450a6421c469935ae165d41252a964, and require both Dockerfiles to move together for future reviewed upgrades.
• Approved overlapping mechanisms: none.

[tavateva]

APPROVE — @ 4c9d09b0. Clean supply-chain hardening; #128 is fully addressed. (Draft PR — mark-ready + merge are yours.)

Grounded the one load-bearing fact — the digest — against Docker Hub's registry API

• The tag currently resolves to exactly the pinned digest. thehale/python-poetry:2.1.3-py3.11-slim's live Docker-Content-Digest is sha256:4e091da0d71700b404a2844ac3bbd4aaa3450a6421c469935ae165d41252a964 — identical to the pin. So this freezes future drift without changing today's image (byte-identical builds now, immutable later). ✅
• It's a single-platform manifest.v2 (linux/amd64; config blob reports Python 3.11.12 / Poetry 2.1.3), not a multi-arch index. That means the pin removes no multi-arch capability — the tag was already single-arch — and it lines up with server-image.yml, whose build-push-action sets no platforms: and so builds amd64-only. Pinning the platform manifest is the correct choice here, not a portability landmine.
• Both Dockerfiles carry the identical digest; the real CI server-image build from Dockerfile-prod on this pin is green.

Acceptance criteria (#128)

1. Both Dockerfile / Dockerfile-prod pin by @sha256 — ✅
2. Bump is an explicit, reviewed digest change — ✅ the new Base Image Pin doc section plus the "both Dockerfiles move together" load-bearing decision in the body.
3. Rebuild from same source + pinned base reproduces the digest — ✅ the drift vector #128 named (mutable base) is closed. (Full bit-reproducibility of the final image also depends on the wheel/pip layers and buildkit — broader than the base pin, and already covered for released images by the certified-digest manifest flow. Out of #128's scope; noted only for honesty.)

Non-blocking

• Swept for other mutable bases: the only others are plugins/plugin-template/backend/Dockerfile{,.gpu} (python:3.10-slim, nvidia/cuda:12.4.1-…). Those are plugin scaffolds, and #128 explicitly treats the nvidia/cuda case as a separate companion concern — correctly out of this PR. Not asking you to touch them here.
• Optional doc nit: the new section says "resolve the new tag's digest" without saying how. A one-liner — e.g. docker buildx imagetools inspect thehale/python-poetry:<tag> and copy the Digest: — would make the next bump turnkey.
• Incidental trailing-newline fix on both Dockerfiles — fine; the files were being edited anyway.

Verification depth

Digest + architecture verified by direct registry pulls on my host (auth.docker.io token → registry-1.docker.io manifest + config blob). CI outcomes (coverage / docs / server-image / test-coverage all green; MERGEABLE / CLEAN) relied on as reported by GitHub, not re-run locally.