fix: unpin the base again; the stand is what catches a bad one

ea8d5e0 pinned `FROM bitnami/haproxy` by digest after the base broke the public
door twice in three days. That is not the trade this project wants: there are no
version tags to pin to, only `latest`, so a pin means a digest raised by hand for
every security update of the base.

What actually catches a bad base is the testnet stand. Watchtower there picks up
each rebuild within seconds, which is precisely how both incidents surfaced —
loudly, on a stand, and not in production. Production runs no Watchtower and is
updated by hand, so a base that breaks the door is seen here first and never
reaches it unattended.

The `ENV OPENSSL_FIPS=no` removal from ea8d5e0 stays. Restoring it would restore
this morning's outage: on the current base "no" is what stops HAProxy loading an
ECDSA certificate. The comment above FROM keeps both measurements, because the
right value depends on the base and the next base may want the other one — that
is the first thing to check the next time this image will not start.

Verified on testnet2 with the image built from this file: config check clean
against the project config and the live certificate, curl 200, TLSv1.3.

docker/Dockerfile

@@ -1,17 +1,34 @@
-# Pinned by digest, and that is the whole point of the line. `FROM
+# Deliberately untagged, and deliberately without an OPENSSL_FIPS of our own.
-# bitnami/haproxy` carries no tag, the scheduled build runs daily, and so this
-# image was rebuilt every morning on whatever the base happened to be — twice
-# in three days that broke the public door with no commit of ours behind it:
-# 2026-09-02 the base began preferring the FIPS provider and TLS 1.3 closed;
-# 2026-09-04 the base changed again and haproxy could no longer load the
-# certificate at all ("inconsistencies between private key and certificate" on
-# a leaf and key that openssl confirms are a pair).
 #
-# This digest is the base measured working on 2026-09-04: haproxy 3.4.4-7f03ae6,
+# The base moves, and twice in three days a move of it closed the public door
-# serving the live testnet2 certificate, curl 200 over TLS 1.3. Bumping it is a
+# with no commit of ours behind it. On 2026-09-02 the base began preferring
-# deliberate act with a check behind it, which is what the last two mornings
+# OpenSSL's FIPS provider — Photon's openssl.cnf reads the preference straight
-# were missing.
+# out of the environment as `default_properties = ?fips=$ENV::OPENSSL_FIPS` —
-FROM bitnami/haproxy@sha256:c3fac4a702bf242262588491e2541f83d870484ddf65e1c91527208dc1156c49
+# and that provider cannot produce an X25519MLKEM768 key, so HAProxy offered a
+# group it could not use and refused every client that asks for post-quantum key
+# exchange. `ENV OPENSSL_FIPS=no` fixed that, and was right for that base.
+#
+# On the 2026-09-04 base it is the other way round: with "no" HAProxy cannot load
+# an ECDSA certificate at all and exits at parse time on `bind *:443`, saying
+# "inconsistencies between private key and certificate" about a leaf and key that
+# openssl confirms are one pair. The base's own "yes" loads it and still
+# negotiates TLS 1.3. Measured on testnet2 against the live certificate, same
+# image, only the variable changed:
+#
+#     OPENSSL_FIPS=no    config check fails at `bind *:443`
+#     OPENSSL_FIPS=yes   config check passes, curl 200, TLSv1.3
+#
+# So the value that is right depends on the base, and hard-coding either one is
+# how the next base move breaks this image. Take what the base ships.
+#
+# The base is not pinned either: there are no version tags to pin to (only
+# `latest` exists), and a digest would have to be raised by hand for every
+# security update. What catches a bad base is the testnet stand — Watchtower
+# there picks up each rebuild within seconds, which is exactly how both of these
+# were found. **Production does not run Watchtower and is updated by hand**, so
+# a base that breaks the door is seen on the stand first. When it happens again,
+# the two lines above are the first thing to check.
+FROM bitnami/haproxy
 
 # The FIPS preference is left exactly as the base ships it, and that is a
 # reversal. The base is Photon OS, whose openssl.cnf reads the variable straight