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/BACKLOG.md

@@ -38,21 +38,33 @@ Plus three backup-pipeline fixes that have never reached prod (`860d483`,
 `567b033`, `898cf48` — the last prod run went green through the whole chain and
 died on the final step wanting `deploy/.env.prod`).
 
-> ### ⚠️ `SES_*` is unset in Gitea, and the renewal sweep is on by default
+> ### `SES_*` secrets created in Gitea 2026-08-02 — unblocked, unverified
 >
-> The variables are wired through both deploy workflows and the app stack, but
-> the secrets were never set. The production image runs `NODE_ENV=production`,
-> which disables the stdout dev fallback, so every send fails and logs
-> `FAILED`.
+> The variables were wired through both deploy workflows and the app stack but
+> had never been set. **They now exist.** What that clears: the production
+> image runs `NODE_ENV=production`, which disables the stdout dev fallback, so
+> a blank config made every send fail and log `FAILED` — and the pólizas sweep
+> defaults to **enabled, 06:00 America/Tijuana**, so the failure would have
+> repeated nightly.
 >
-> The pólizas sweep defaults to **enabled, 06:00 America/Tijuana**. Deploying
-> current master with SES still blank means a sweep that fails every single
-> night, silently except for the log.
+> **Not yet confirmed, and the first deploy is what confirms it:**
 >
-> **Before cutting `v1.0.7`:** either set the Gitea secrets, or disable the
-> pólizas schedule at `/notificaciones` → "Programación de envíos" first.
-> See [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md) and
-> [`DEPLOY_AND_MIGRATIONS.md`](DEPLOY_AND_MIGRATIONS.md).
+> 1. **Names match.** The preflight checks `SES_REGION`, `SES_FROM`,
+>    `SES_ACCESS_KEY`, `SES_SECRET_KEY` and warns by name if any is blank —
+>    read that warning on the next run. No `_GALACTUS` suffix on any of them;
+>    one SES identity serves every deployment.
+> 2. **`SES_FROM` is a verified identity in `SES_REGION`.** An unverified
+>    sender is rejected per-send, which looks identical to a missing config in
+>    the log.
+> 3. **The AWS account is out of the SES sandbox.** This is the one that would
+>    hurt: in sandbox, SES only delivers to *verified* recipients, so a renewal
+>    sweep across 815 policyholders would fail almost every send while the
+>    config looks entirely correct. Check before letting a real sweep run.
+>
+> Until 2 and 3 are confirmed, run the first sweep with `debug` on — it diverts
+> every recipient to the override inbox, and on the pólizas side it also leaves
+> the avisos pending, so nothing is consumed by a failed test. See
+> [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md) "Send flags".
 
 Also outstanding on the deploy path: every pre-existing database still needs
 its one-time `prisma migrate resolve --applied 0000_init`.