Phase 10: deployment (Apache compose + proxy fragments, CI release) + docs

- deploy/docker-compose.yml: pinned-tag ghcr image, hardened (cap_drop ALL +
  minimal cap_add, no-new-privileges, panel bound to 127.0.0.1 only). Apache
  itself runs on the host (spec 10.5), fragment at deploy/apache/.
- Alternative reverse-proxy fragments: nginx (+certbot sidecar), Caddy
  (automatic ACME), Traefik (+acme.json PEM extraction script).
- .github/workflows/release.yml: tag-triggered ghcr.io publish, version piped
  from the git tag into both the binary ldflags and the image tag (spec 10.1).
- Closed a gap from Phase 1: logrotate was installed but never invoked;
  wired up build/logrotate-mail.conf + logrotate-loop.sh + a supervisor
  program (copytruncate, since postlogd holds mail.log open with nothing to
  signal on rotation).
- README rewritten: site requirements checklist, reverse-proxy comparison,
  DNS setup (server- vs domain-level), IP warmup, backup/restore vs domain
  export/import, fixed-tag rationale, machine requirements.

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

build/logrotate-loop.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+# Periodic logrotate for /var/log/mail.log (spec 9, 10). Postfix's maillog_file
+# is written by postlogd, which keeps the file open for the life of the
+# process — there is no daemon to signal on rotation, so the logrotate.d config
+# uses copytruncate (a brief truncation race can drop the last few in-flight
+# lines, which is an acceptable trade for not having to reload Postfix on every
+# rotation).
+#
+# logrotate itself only rotates once the configured "daily" period has elapsed
+# (tracked in /var/lib/logrotate/status), so it is safe to invoke this more
+# often than daily — polling merely bounds how late a legitimate rotation runs.
+set -eu
+
+INTERVAL="${LOGROTATE_INTERVAL_SECONDS:-21600}"
+
+while true; do
+	if logrotate /etc/logrotate.d/mail; then
+		:
+	else
+		echo "logrotate-loop: logrotate failed, will retry after ${INTERVAL}s" >&2
+	fi
+	sleep "${INTERVAL}"
+done