Greenfield transactional email stack: dispatcher chokepoint, admission+egress guards, durable outbox

Elazar directive 2026-08-01: every evolutiva app gets a full email-send workflow. Enamel measured NULL - no transactional app mailer (deps, call sites, .env.local absent, 3 Vercel vars all Supabase) AND GoTrue cannot send (external_email_enabled=false, all smtp_* NULL, one true provider). So this is BUILD, not migrate: no sender identity exists to carry. Class-A under Push-to-Done (email-send path): audit design-ping BEFORE implementing, diff review before push, build+runtime logs after. Design requirements settled 2026-08-01 across three sibling specs + pmmaster rulings: (1) TWO separately-named recipient guards, never merged - ADMISSION allowlist (allowedEmailDomains, input-side; on no app's SMTP path) and EGRESS deliverability classifier at the transport chokepoint (venus email-recipient-guard-core is the only live impl; mars+pluto lack it). (2) Outbox-first durable send, enqueue on the caller's transaction. (3) Drain via Supabase pg_cron + pg_net; vercel.json cron CANNOT do sub-daily (Hobby-illegal, fails the build, froze mars prod 31h). (4) Bounded SMTP timeouts every phase, retry only genuinely transient. (5) resolveSiteOrigin fail-closed - pluto src/lib/site-config.ts is the SOLE fleet reference; mars is NOT remediated (5 bare NEXT_PUBLIC_APP_URL fallbacks at 45e1a0b, 4 on the mail path, MARS-599 open). (6) Never ride GoTrue's mailer - satisfied VACUOUSLY today, state as a dated condition not a property (one un-notified dashboard toggle from false). (7) appEvents on send AND fail - pluto's success row fires only on the immediate path, do not copy that. (8) From header must be a verified Gmail send-as or it is silently re-stamped (pluto PLUTO-131).