Remove magic-link flow entirely — OTP for auth, in-band invite acceptance

Decision

Chitragupt has no magic-link flow. Email verification is OTP (already canonical per 2026-06-24-email-verification-otp). Sign-in is OTP. Family and CA invite links route the user directly to sign-up / sign-in with the invite token in the URL; there is no separate "accept invite" landing page.

Why

The dedicated magic-link landing page (auth/magic-link-accept.html) duplicated the sign-up/sign-in surfaces and added a click step. Removing it collapses two surfaces into one and matches the OTP direction already set for verify-email.

Impact

• .context/designs/{website,mobile}/auth/magic-link-accept.html deleted.
• .context/wiki/surfaces/auth-magic-link-accept.md deleted.
• The two superseded ADRs (2026-06-24-magic-link-wireframe-alignment, 2026-06-24-provider-inbox-links-magic-link-sent) are now obsolete.
• 2026-06-24-family-invite-landing stays canonical — its principle ("invite link is a routing signal, not an auth mechanism") is preserved; the implementation is now inline on sign-up rather than on a separate landing page.
• Family-invite emails route to /auth/sign-up?invite=<token> (or /auth/sign-in?invite=<token> for existing accounts). The sign-up surface shows the inviter context inline.
• All "magic link" user-facing copy in wireframes and app code replaced with OTP / 6-digit-code language, or with "invite link" where the context is invite-acceptance routing.
• .context/features/index.md Phase 1 exit criterion now reads "sign up via email OTP" instead of "sign up via magic link".
• Affects copy-strings, tier-pro-family, auth-sign-in, auth-sign-up, auth-verify-email.

Status

Active.

Sources

• User direction 2026-06-27 wireframe consistency sweep.
• 2026-06-24-email-verification-otp (established OTP direction for verify-email).
• 2026-06-24-family-invite-landing (established that invite link is a routing signal).