New-account send throttling: spread sends over the day for the first 30-60 days (hosted) #73

Background

New hosted accounts can send their whole list immediately. There's no ramp for new accounts:

• The sequence worker runs at concurrency: 10 with no transport rate limit (Per-ESP send-rate limiting (e.g. SES max send rate) #51).
• The only volume control is a flat per-team daily/monthly quota:
  • organizationDeliveryPolicies.defaultDailyLimit (apps/api/src/db/schema.ts:984)
  • enforced in apps/api/src/delivery/quota.ts
  • not age-aware

A brand-new account blasting tens of thousands of messages at once is the classic abuse pattern. It's also bad for deliverability on a cold domain, which is the warm-up fear beehiiv switchers raise. Source: Jesse Hanley's anti-abuse checklist (shared by Marc Lou on X, 18 Oct 2026).

This is different from #51. #51 is about ESP per-second limits (e.g. SES max send rate). This issue is about platform policy: spread a new account's sends over the day for its first 30-60 days.

Related: #51 (per-ESP rate), #5 (automatic warm-up scheduler) and #67 (day-one warm-up guide and caps). Part of #75 (hosted abuse prevention umbrella). This blocks inviting public users.

Proposed fix

• Add an account-age-based delivery policy for hosted orgs. For the first N days (configurable, default 30, up to 60), cap sends per hour and per day, ramping with account age and with bounce/complaint history. Broadcasts are delivered spread across the day, not in a single burst.
• Implement it as scheduling in the broadcast fan-out: assign per-message send times, and keep the existing quota buckets in delivery/quota.ts. Combine it with Per-ESP send-rate limiting (e.g. SES max send rate) #51's per-ESP token bucket.
• Show the user that a broadcast is "sending gradually (new account)" with an ETA. Admins can lift the limit early for vetted accounts.
• Hosted-only; self-host defaults off.

Acceptance criteria

• Orgs younger than the configured window have their broadcasts paced across the day (tested with a large audience)
• Ramp schedule is configurable; admins can exempt an org
• UI and API show paced status and the expected completion time
• Works together with Per-ESP send-rate limiting (e.g. SES max send rate) #51 per-ESP limits and the daily quota without double-blocking
• Off by default for self-host