fix(docker): bump OpenSSL to 3.5.7-1~deb13u3 and pin python base by digest

[jpiaseck]

Problem

All 24 service images built from python:3.11-slim-trixie fail to build:

The following packages will be DOWNGRADED:
  libssl3t64 openssl openssl-provider-legacy
E: Packages were downgraded and -y was used without --allow-downgrades.

The upstream python:3.11-slim-trixie tag was rebuilt with OpenSSL 3.5.7-1~deb13u3 (now in trixie-security), while the Dockerfiles pin openssl=3.5.7-1~deb13u2. Because the base is referenced by a floating tag, the exact apt pin turns into a downgrade every time Debian ships an OpenSSL update and the base is rebuilt.

Fix

• Bump openssl / libssl3t64 / openssl-provider-legacy to 3.5.7-1~deb13u3 in the 24 Dockerfiles that carry the pin.
• Pin the base image by digest via a new python_image_digest ARG:

  ARG python_image_digest=sha256:bab1b7ef4b450c81002278d035eff85ebe394ae94df904f7a3ba14f7e16e487b
  FROM python:${python_image_version}@${python_image_digest}

  bab1b7ef… is the current multi-arch index digest of python:3.11-slim-trixie (Python 3.11.17, Debian 13.7, OpenSSL 3.5.7-1~deb13u3).

With the digest pinned, the base — and the OpenSSL it ships — only changes when the digest is bumped explicitly, together with the openssl pin. Future upstream rebuilds no longer break the build, and published Dockerfiles stay reproducible.

To bump in the future: update python_image_digest to the new python:3.11-slim-trixie digest and the openssl pin to the version that base ships, in the same change.

Testing

Built locally with deployment/update_images.sh --build (no push):

• 22 / 24 images built and verified: openssl, libssl3t64 and openssl-provider-legacy are all 3.5.7-1~deb13u3, Python 3.11.17, and the bottom 4 layers of every image match the pinned base digest exactly.
• Not yet verified: textExtractorUsvc and ttsFastapiModelServer — their builds were interrupted by a local disk-space issue, not a build error. The change to those two Dockerfiles is identical to the other 22.
• Not done: runtime smoke tests of the built images.

Note (pre-existing, not changed here)

ingestion and prompt_template Dockerfiles do not contain the rm -f /usr/bin/dmesg /usr/bin/base64 /usr/bin/perl hardening step that the other images have, so those binaries remain in those two images. Left out of scope for this PR.