Email anonymous registrations a confirmation link that signs them in

[sethherr]

An anonymous register-flow registration can't create its bike — Ownership needs a creator — so step 1 now emails the address a link. Following it proves the address, creates a passwordless account, signs them in, and creates the bike the registration was holding, dropping them on whatever step they're on.

• The link carries its own single-use token, minted only in the send path, bound to the address it was mailed to, and spent on use. The registration's id_token is already in the registrant's URL before any email goes out, so a click carrying it would prove nothing about who received what. Binding matters because step 1 stays resubmittable: without it, editing owner_email after the link went out would let that link confirm — and sign you in as — an address you never received mail at.
• BParam::TOKEN_EXPIRATION (90 days) governs both the link and how long the register flow resumes by token, since a link outliving the registration it resumes is a dead end. The confirm lookup applies no window of its own, so an expired link can say so and send a new one rather than dumping them into a fresh registration.
• The landing page only renders a form that posts itself via Sign users in from emailed links instead of a password #4019's auto-submit controller — a link scanner's GET can't spend the token. Resends are rate limited off a stamp written by the sender, not by the delivering job.
• The account it makes is a passwordless_user, so it gets Sign users in from emailed links instead of a password #4019's offer to set a password like every other emailed sign in; an address that already has an unconfirmed account gets confirmed, as the magic link does. Creating one moves out of Users::ProcessOrganizationRoleJob into UserServices::PasswordlessCreator, and the non-redirecting half of Sessionable#sign_in_and_redirect becomes sign_in_user, so this lands in the same session state as every other sign in.
• The email rides on Email::PartialRegistrationJob, which now takes the notification kind alongside the id — it and partial_registration are the two a registration sends before it has a bike, so they share the domain check and the notification. Both are seeded now, since nothing else leaves a b_param mid-flow for the mailer previews.

New accounts still land on the terms-of-service gate the first time they visit their account — same as passwordless org accounts. If step 1's submit should count as acceptance, that's a follow-up.

[sethherr]

Screenshots

/register?step=2

The "we've sent a confirmation link" banner is unchanged — only the predicate behind it moved to BikeServices::Register.confirmation_email_pending?, so this pair documents visual parity.

Desktop	Mobile
main 👆	this branch 👇

/rails/mailers/organized_mailer/partial_register_confirmation

New email, so there's nothing on main to compare against. Rendered off the seeded Brakebills registration, so the org's header/footer snippets are in it.

Desktop	Mobile

/register/confirm isn't captured — it auto-submits on load via the auto-submit controller, so a screenshot races the redirect and each attempt spends the single-use token.