docs: SES secrets created, ship blocker cleared

Five documents asserted the SES_* secrets were unset in Gitea. They now
exist, so all five are corrected rather than leaving the claim to rot in
whichever one a reader opens first.

Replaces the blocker with the two things creating the secrets does NOT
establish, since both fail in ways that look identical to a missing
config: SES_FROM must be a verified identity in SES_REGION, and the
account must be out of the SES sandbox — in sandbox SES only delivers to
verified recipients, so a sweep across 815 policyholders would fail
almost every send while the configuration reads as correct.

Recommends running the first sweep with debug on, which diverts every
recipient and, on the pólizas side, leaves the avisos pending so a failed
test consumes nothing.

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

docs/DEPLOY_AND_MIGRATIONS.md

@@ -335,5 +335,10 @@ backup does them (see `deploy/scripts/pre-migrate-backup.mjs`):
   which has no DB lock (the pólizas one does). Keep it single-replica.
 - `SES_*` is optional to deploy — the preflight only warns — but the production
   image sets `NODE_ENV=production`, which disables the stdout dev fallback. A
-  blank SES config therefore makes every send fail and log `FAILED`. As of
-  2026-08-02 these secrets are still unset in Gitea.
+  blank SES config therefore makes every send fail and log `FAILED`. The
+  secrets were created 2026-08-02; the preflight warning on the next run is
+  what confirms the names are right. Two things it cannot check: that
+  `SES_FROM` is a **verified identity** in `SES_REGION`, and that the account
+  is **out of the SES sandbox** (in sandbox, delivery is restricted to verified
+  recipients, which would fail a real sweep while looking correctly
+  configured).