feat(deploy): continuous WAL archiving to S3 for point-in-time recovery

Add pgBackRest-based PITR for the production database, shipped disarmed
(archive_mode and the base-backup timer gated off) so it stays inert until the
operator arms it before real payments — an un-armed deploy cannot pile WAL onto
the disk.

- Postgres now builds from a thin image carrying pgBackRest (archive_command runs
  in-process); the prod overlay wires an encrypted (AES-256-CBC), path-style S3
  repository with 30-day retention and a daily full base-backup systemd timer.
- Repository config/secrets flow through the PROD_PGBACKREST_* Gitea set and
  write-prod-env.sh; prod-rollback re-renders the same env so a rollback cannot
  disarm archiving.
- Grafana alerts watch pg_stat_archiver (failing / stalled), absent-safe on the
  test contour, which never archives.
- Fix the pre-migration pg_dump to snapshot the whole database (was backend-only,
  silently excluding payments).
- Document the PITR runbook, the arming sequence and the restore drill in
  deploy/README.md; record the measured cost/perf assessment.

deploy/postgres/Dockerfile

@@ -0,0 +1,12 @@
+# Postgres for the Scrabble contour, extended with pgBackRest for continuous WAL
+# archiving and point-in-time recovery. pgBackRest must live in the database container
+# because Postgres runs archive_command in-process; the scheduled base backups and the
+# manual restore drills invoke the same binary through `docker exec`, inheriting the
+# repository configuration from the container environment.
+#
+# Archiving is enabled only on the production main host, where the prod overlay
+# (docker-compose.prod.yml) sets archive_mode and supplies the S3 repository. On the test
+# contour this image behaves exactly as a plain postgres:17-alpine. See deploy/README.md
+# (point-in-time recovery).
+FROM postgres:17-alpine
+RUN apk add --no-cache pgbackrest