Stage a signup and mail a code. Creates no account.

The guard stack is the one /api/onboarding/self-serve already runs, in the same order: IP limit, global cap, honeypot, per-address cap, then proof of the mailbox. It diverges in one place, deliberately. Onboarding answers an over-cap address with a 429 whose text confirms we have seen it before; here every outcome returns the same body, because this file's standing rule is one code path with one observable, and hs_login two hundred lines up goes to considerable trouble for exactly that property. Losing it on the signup route would be an odd place to stop caring.

The send is awaited, which the authenticated routes below must not do. It is correct here: no session exists yet, so response time correlates with nothing about an existing partner, and the person genuinely needs to be told if the code could not be sent.