Ops: confirm Supabase Auth upstream SMTP provider (transactional email DPA disclosure)

[PetrefiedThunder]

Context

During the trust-and-safety subprocessor sweep (#2298, #2301), the Trust Center subprocessor row for Supabase was updated to flag "auth confirm/reset/invite emails currently rely on Supabase's built-in mailer." That note exists because no `GOTRUE_SMTP_*` overrides are set in Railway today, which means Supabase routes auth emails through its built-in (default) SMTP transport.

Supabase's built-in mailer:

• Has a low send rate limit (3-4/hour per project) — not production-grade
• Uses Supabase's own infrastructure as the upstream (not visible to the customer)
• Doesn't surface delivery analytics

Decision needed

1. Should we wire a contracted SMTP provider for Supabase Auth (Resend is already a subprocessor — natural fit; SendGrid / Postmark are alternatives)?
2. If yes — set `GOTRUE_SMTP_HOST`, `GOTRUE_SMTP_PORT`, `GOTRUE_SMTP_USER`, `GOTRUE_SMTP_PASS`, `GOTRUE_SMTP_ADMIN_EMAIL`, `GOTRUE_SMTP_SENDER_NAME` in Railway. Update DPA SUBPROCESSORS to flag the SMTP transport explicitly.
3. If no — accept the rate-limit ceiling and document the operational risk (a sign-up burst above 3-4/hr will silently delay confirmation emails).

Why this matters

• DPA accuracy: customers reading `/dpa` need to know what subprocessor handles password-reset emails and account-confirmation emails — those messages contain user PII (email + tenant context).
• Production reliability: free-tier Supabase mailer is the wrong choice if signup volume picks up. Better to rip the bandage now than discover during a launch.
• Resend is already a paid subprocessor for app-level transactional email (contact form, alerts) so adding SMTP routing to the same vendor is low overhead.

Files that depend on the answer

• `frontend/src/app/trust/page.tsx` — subprocessor table
• `frontend/src/app/dpa/page.tsx` — `SUBPROCESSORS` array Supabase row
• `frontend/src/app/privacy/page.tsx` — auth-email disclosure
• Railway env vars — `GOTRUE_SMTP_*` set

Acceptance criteria

• Decision recorded in `memory/` or `docs/architecture/`
• Supabase row in DPA + Trust Center reflects the actual SMTP transport
• If routing through Resend: env vars set, send-from address verified

[PetrefiedThunder]

Decision memo: #2343 (docs/decisions/2026-05-12-supabase-smtp.md).

Recommendation: Option A — route Supabase Auth through Resend SMTP via GOTRUE_SMTP_* (Supabase dashboard, not Railway). Only resetPasswordForEmail depends on the built-in mailer today; signup uses email_confirm=True and invites are already on Resend. No blocker — apex regengine.co is verified, auth.regengine.co subdomain verification is the only prereq.

[PetrefiedThunder]

Decision ratified: Resend SMTP. See PR #2350 for the locked-in decision artifact and #2352 for the implementation checklist (verify sender → DPA update → Supabase dashboard config → test send).