fix: repair issuance, verify installation, reach HAProxy over a unix socket

Setting CERTBOT_EMAIL broke certificate issuance outright. CERTBOT_OPTS was
built as "--email $CERTBOT_EMAIL" and passed quoted, so certbot received the
flag and its value as one argument and rejected it as unrecognised; `set -e`
then ended the pass, and the loop repeated the same failure every 12 hours
while the site served the self-signed placeholder. The arguments are built
with `set --` now, which keeps them two words.

Installation into the running HAProxy reported success whatever happened. The
runtime API answers a refusal in the reply text and still closes cleanly, so
socat exits 0 either way; the script sent set, commit and show in a row and
inspected none of them. It now matches the replies and stops at the first that
is not an acknowledgement, saying plainly that the running HAProxy is still on
its previous certificate. It also reaches the API over a unix socket on a
volume shared with haproxy rather than TCP 9999, so the private key it carries
no longer crosses a network in the clear.

Also:

- The self-signed placeholder wrote site.key, site.csr and site.crt to the
  working directory (/opt/certbot) and left the private key there for good.
  It is built in a subshell under umask 077 on the volume the key belongs on,
  the CSR step is gone, and `>>` is replaced by a temporary file and an atomic
  rename — HAProxy reads site.pem at start-up and must never find it partial.
- 2-concatenate-cert.sh changed into the live directory without checking, and
  on failure looked for fullchain.pem in whatever directory the caller was
  sitting in — the scripts are sourced, so that is a real possibility. It uses
  absolute paths and reports when there is nothing to concatenate.
- The wait for HAProxy watches for the runtime API socket instead of probing
  TCP 9999, which no longer exists.
- compose: /var/lib/letsencrypt is declared a VOLUME by the base image, so
  leaving it unnamed created a fresh anonymous volume on every container
  creation. It and the volumes section, which was missing entirely, are added.
  Build context is the repository root, as the Dockerfile's COPY expects.

Verified on testnet2 against a real unix socket: the happy path sends set,
commit and show; a refused set stops before commit; a refused commit and an
unreachable socket are both reported. The runtime API payload is byte-identical
to what the previous echo produced.

docker/scripts/3-update-haproxy-cert.sh

@@ -1,12 +1,67 @@
 #!/bin/sh
 
-# Start transaction
-echo -e "set ssl cert /usr/local/etc/haproxy/certificates/site.pem <<\n$(cat /etc/certificates/site.pem)\n" \
-  | socat - tcp-connect:haproxy:9999,retry=30,interval=2,connect-timeout=5
+# Install /etc/certificates/site.pem into the *running* HAProxy over its runtime
+# API — no restart, no dropped connections.
+#
+# Every answer is inspected. The runtime API reports a refusal in the reply text
+# and still closes the connection cleanly, so socat exits 0 either way: the
+# unchecked version sent set, commit and show in a row and reported success
+# while HAProxy went on serving the old certificate. If HAProxy ever reworded
+# these replies the checks would raise a false alarm, which is the safe
+# direction for the error to point — site.pem on the shared volume is correct
+# regardless, and HAProxy loads it from there on its next restart.
 
-# Commit transaction
-echo "commit ssl cert /usr/local/etc/haproxy/certificates/site.pem" | socat tcp-connect:haproxy:9999 -
+CERT_PATH=/usr/local/etc/haproxy/certificates/site.pem
+SRC=/etc/certificates/site.pem
+# A unix socket on a volume shared with HAProxy, not a TCP port: the private key
+# below travels this channel in the clear, and file permissions are the only
+# access control a container-to-container path can have.
+API="UNIX-CONNECT:/var/lib/haproxy/admin.sock"
 
-# Show certification info (not essential)
-echo "show ssl cert /usr/local/etc/haproxy/certificates/site.pem" | socat tcp-connect:haproxy:9999 -
+update_haproxy_cert() {
+  if [ ! -s "$SRC" ]; then
+    echo "3-update-haproxy-cert.sh: $SRC is missing or empty, nothing to install" >&2
+    return 1
+  fi
 
+  # Start transaction. The payload ends with a blank line — that is what closes
+  # a << block on the runtime API. retry= is what waits out a HAProxy that is
+  # still coming up.
+  answer=$(
+    printf 'set ssl cert %s <<\n%s\n\n' "$CERT_PATH" "$(cat "$SRC")" \
+      | socat - "$API,retry=30,interval=2" 2>&1
+  ) || {
+    echo "3-update-haproxy-cert.sh: cannot reach the HAProxy runtime API: $answer" >&2
+    return 1
+  }
+
+  case "$answer" in
+    *"Transaction created"*) ;;
+    *)
+      echo "3-update-haproxy-cert.sh: HAProxy refused the certificate: $answer" >&2
+      return 1
+      ;;
+  esac
+
+  # Commit transaction
+  answer=$(echo "commit ssl cert $CERT_PATH" | socat - "$API" 2>&1) || {
+    echo "3-update-haproxy-cert.sh: cannot reach the HAProxy runtime API: $answer" >&2
+    return 1
+  }
+
+  case "$answer" in
+    *Success*) ;;
+    *)
+      echo "3-update-haproxy-cert.sh: HAProxy refused to commit the certificate: $answer" >&2
+      return 1
+      ;;
+  esac
+}
+
+if update_haproxy_cert; then
+  # Show certification info (not essential) — it is what puts the live
+  # certificate's dates in the container log.
+  echo "show ssl cert $CERT_PATH" | socat - "$API" 2>&1 || true
+else
+  echo "3-update-haproxy-cert.sh: the running HAProxy still serves its previous certificate" >&2
+fi