feat(ops): nightly database backups with rotation (RECOMMENDATIONS #3)

Adds a compose 'backup' sidecar: daily pg_dump of the inboxintel DB into ./backups
(git-ignored), atomic write (.tmp -> rename), rotation after BACKUP_KEEP_DAYS
(default 7). Previously there were NO backups — a bad migration or volume loss
meant total data loss. Restore procedure documented in compose + SECURITY.md.

Verified: compose config parses; a live pg_dump against the staging DB produced a
valid dump over the compose network with the same image/credentials the sidecar uses.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

SECURITY.md

@@ -29,7 +29,9 @@ reverse proxy.
    mitigate (a third party reading the DB files) reduces to "someone with access to your
    machine" — mitigate it at the layer that actually works:
    - **Use full-disk or volume encryption** on the host (BitLocker/LUKS) — strongly recommended.
-   - **Encrypt backups** of the `pgdata` volume the same way.
+   - **Encrypt backups**: nightly `pg_dump` rotation runs via the compose `backup` service
+     into `./backups/` (git-ignored) — keep that directory on an encrypted disk and copy it
+     off-machine. Restore: `docker compose exec -T postgres psql -U inboxintel -d inboxintel < backups/<file>.sql`.
    - Before any **multi-user** deployment, revisit per the multi-provider security design
      (host admins must not be able to read members' mail — plaintext bodies break that promise).
 2. **DB connection is not TLS** — Postgres is only reachable on the compose-internal network /