Enterprise Waitlist

Public — does NOT honour require_billing_enabled.

Inbound demand-capture for the published Enterprise tier on /pricing (BIZ-007 §6 step 1). §7 gates all further Enterprise build-out on ≥3 enterprise_waitlist entries; this endpoint is what makes that gate measurable. Mirrors notify_me's storage (lower-case + email UNIQUE idempotency) but NOT its response shape: an unauthenticated caller must not learn whether an address was already on the list, so the insert and the duplicate path both return the identical {queued: true} (security-auditor finding on PR #492 — enumeration oracle closed here rather than inherited from the pro_waitlist precedent). Available regardless of BILLING_ENABLED — Enterprise is inbound-only and never touches Stripe checkout.

CAPTURE is deliberately unthrottled beyond the shared RateLimitMiddleware "write" bucket (60 RPM per IP) that fronts /notify-me: a tighter capture bucket would cost real Enterprise leads to stop junk rows we can scrub from /admin, and a lost lead is lost revenue. The two costs a flood actually imposes are bounded elsewhere instead —

• outbound EMAIL, by two layers in _notify_enterprise_lead: the per-SOURCE daily allowance (app/services/lead_capture_budget.py, residual finding 5 of the PR #599 review) in front of the GLOBAL hourly+daily ceiling (app/services/notification_budget.py, security-auditor finding 2 on PR #519);
• junk ROWS, by the enterprise_waitlist retention family in app/services/auth_retention_service.py, which prunes only never-contacted rows past a long window.

Neither can reject a signup: the row commits first and this response is identical either way.