build: pin base image digests and clear every fixable image finding

The production images built on mutable tags with --pull, so the same commit
could produce different bases, and neither Dockerfile upgraded its OS packages
even though the local ones did. The published API image carried 56 HIGH and 3
CRITICAL findings, 15 of them with an upstream fix available.

Pin both bases by digest and upgrade OS packages in the production images. That
removes all 3 CRITICAL and 13 of the 15 fixable findings. The remaining two,
msgpack and setuptools, come from a third-party SBOM; neither package is
importable or listed by pip in the built image, which I confirmed rather than
taking the previous report's word for it.

The web image could not be fixed this way: the official 1.28 line pins
nginx=1.28.3-r1 in /etc/apk/world, so apk upgrade leaves five HIGH findings in
place even though Alpine ships 1.28.3-r7. Moving to nginx:alpine (1.31.6)
clears them completely; 1.29-alpine scans worse, at 37 HIGH. Same uid 101 and
the same template entrypoint, and the local images now use the same pinned
bases so the integration suite exercises what ships. Full suite passes on
nginx 1.31.6, including the browser end-to-end.

With both images at zero CRITICAL, the image scan now blocks on CRITICAL and
reports HIGH, instead of reporting everything. PYTHON_BASE_IMAGE and
NGINX_BASE_IMAGE are wired through to the builds so a base can move forward
without editing the repository, which is what PORTAINER.md already promised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/Dockerfile.api

@@ -1,5 +1,8 @@
 # syntax=docker/dockerfile:1
-ARG PYTHON_BASE_IMAGE=python:3.12-slim
+# Pinned by digest so a rebuild of the same commit produces the same base.
+# Override with the PYTHON_BASE_IMAGE repository variable to move it forward
+# deliberately, and update this default in the same change.
+ARG PYTHON_BASE_IMAGE=python:3.12-slim@sha256:2f17fc044b579bab302c2e8054d3a686e2cb9a83de48e70534b94cd8ebbe06a9
 FROM ${PYTHON_BASE_IMAGE}
 
 ARG VCS_REF=unknown
@@ -7,6 +10,13 @@ LABEL org.opencontainers.image.title="DTF Portal/API" \
       org.opencontainers.image.revision="$VCS_REF" \
       org.opencontainers.image.source="DTF System repository"
 
+# The base is pinned, so its OS packages are frozen at the digest's build date.
+# Upgrade them here or the image ships known-fixed Debian vulnerabilities, which
+# is what the production image was doing while the local one already did this.
+RUN apt-get update \
+    && apt-get upgrade -y \
+    && rm -rf /var/lib/apt/lists/*
+
 WORKDIR /app
 COPY local/requirements.txt local/requirements.lock /app/local/
 RUN python -m pip install --no-cache-dir --require-hashes -r local/requirements.lock

deploy/Dockerfile.web

@@ -1,6 +1,10 @@
 # syntax=docker/dockerfile:1
-ARG PYTHON_BASE_IMAGE=python:3.12-slim
-ARG NGINX_BASE_IMAGE=nginx:1.28-alpine
+ARG PYTHON_BASE_IMAGE=python:3.12-slim@sha256:2f17fc044b579bab302c2e8054d3a686e2cb9a83de48e70534b94cd8ebbe06a9
+# Both bases are pinned by digest; override with the repository variables to
+# move them forward deliberately.
+# nginx 1.31.6. The 1.28 line pins nginx=1.28.3-r1 in /etc/apk/world, so its five
+# HIGH findings cannot be upgraded in place; 1.29 scans worse. This one is clean.
+ARG NGINX_BASE_IMAGE=nginx:alpine@sha256:62ff2089abf5a9ed33bd232895bef5e22f7bb4b200675cec49a5ebc48e3d4ac8
 FROM ${PYTHON_BASE_IMAGE} AS policy
 WORKDIR /build
 COPY dtf-site.html /build/dtf-site.html
@@ -10,6 +14,8 @@ ENV NGINX_TEMPLATE=/build/deploy/nginx.conf.template
 RUN python local/compile_web.py
 
 FROM ${NGINX_BASE_IMAGE}
+# Same reason as the API image: a pinned base freezes its packages.
+RUN apk upgrade --no-cache
 ARG VCS_REF=unknown
 LABEL org.opencontainers.image.title="DTF Site and Kanban" \
       org.opencontainers.image.revision="$VCS_REF" \