AUTH-006 — Offer simple email/password and Google sign-in

[daliu]

Problem

The current /login screen supports email/password sign-in, account creation, password reset, and email verification, but it has no Google Auth option. Some event and registration prompts also link to /login without preserving the member's intended destination. This adds avoidable steps for members, especially elderly or nontechnical members, and risks inconsistent sign-in behavior across membership, navigation, and future payment journeys.

User and UX invariant

MPRC account entry offers two plain-language choices on one screen:

1. Continue with Google — one primary action using Firebase's supported Google provider.
2. Use email — preserve email/password sign-in, create-account, verification, reset, and password-manager support.

Choosing an identity provider proves control of an account only. It never proves current MPRC membership, dues payment, discount eligibility, member pricing, or admin authority.

The journey must minimize steps, avoid provider/security jargon, use large readable controls, provide one clear next action in every state, and keep keyboard, screen-reader, mobile, and password-manager behavior first-class.

Atomic scope

• Add identity-only Google sign-in/sign-up through Firebase Auth; request no Drive, Sites, Groups, Directory, Contacts, or other Google scopes.
• Put Continue with Google and the email/password path together on the existing /login page without hiding either behind an unexplained mode.
• Preserve email account creation, verification email, resend/reset behavior, and generic anti-enumeration errors.
• Reuse AUTH-005 — Return users to the intended protected page after sign-in #96's safe internal return-path validator after either sign-in method.
• Make event, registration, membership, and other sign-in prompts preserve pathname, query, and hash so users return to the task they started.
• Handle popup cancel/block, redirect resume if used, provider disabled, offline/error, repeated click, loading, and account-collision states without dead ends.
• For a same-email/different-provider collision, never auto-link or create a duplicate account. Direct the member to sign in with email first and complete the explicit AUTH-004 — Link a Google identity to an existing Firebase member account #82 linking/recovery flow.
• Add focused service and real-component tests using synthetic identities only.
• Add a short officer/provider checklist for enabling Google Auth and authorized domains in a non-production environment; provider-console changes require a named owner and private evidence.

Acceptance criteria

• The first auth screen visibly offers Continue with Google and email/password; neither method removes the other.
• A new Google-authenticated Firebase user starts account-only/pending (unverified) and receives no membership, discounts, member price, or admin claim from Google email/provider data.
• A linked returning Google user keeps the existing Firebase UID and data.
• An existing email/password user is never silently duplicated or linked by email; the collision path is clear, generic, and points to the explicit AUTH-004 — Link a Google identity to an existing Firebase member account #82 flow.
• Email sign-in, create-account, verification, resend, reset, password-manager autocomplete, and existing generic failure behavior remain functional.
• Google success and email success return to the same validated intended route; unsafe or missing targets fall back to /account.
• Sign-in prompts from event registration and other gated journeys preserve the intended route, query, and hash.
• Loading disables every competing auth action; double-click cannot start duplicate attempts.
• Popup cancellation is quiet and recoverable; popup-blocked/redirect behavior is tested on mobile-sized and desktop flows.
• Controls have clear visible labels, keyboard focus, readable status/error text, and announced loading/error/success states without relying on color alone.
• No Google access token, raw provider response, private email list, or auth error detail appears in Firestore profiles, custom claims, analytics, logs, issues, or user-visible errors.
• Local/CI tests use the Auth emulator/mocks and never contact production. Staging evidence identifies provider enablement, authorized domains, safe return, account collision, and first-sign-in default-role behavior.
• Account creation stays separate from dues/payment/membership activation. Server-authoritative event pricing and future payments must consume membership state, never auth-provider choice.

Dependencies and coordination

• Completed foundations: AUTH-005 — Return users to the intended protected page after sign-in #96 (safe return routing) and source-merged AUTH-001A — Reject unverified targets at existing role-grant endpoints #98 (unverified-target role grants; Firebase deployment still unproven).
• Implementation dependencies: SAFETY-001 — Preserve callbacks and fail closed on local Firebase isolation #99 (fail-closed Auth/Functions emulator isolation), CI-001A — Repair the deterministic frontend test baseline #103 (deterministic frontend test baseline), MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81 (authoritative membership/account state), and AUTH-004 — Link a Google identity to an existing Firebase member account #82 (existing-account Google linking/collision recovery).
• Remaining AUTH-001/AUTH-002 and protected deployment work must be complete before production membership use.
• Parent: COMMUNITY-EPIC — Unified member access and community integrations #79. Protected discounts consumer: MEMBERS-CONTENT-001 — Build the Firebase-native members-only discounts page #83.
• Google provider enablement, OAuth consent/authorized domains, and production evidence are owner actions; source code does not prove them configured.

Expected implementation paths are limited to the identity service/hook, login component/tests, and sign-in entry-point navigation tests. Do not touch Firestore Rules, membership schemas, Stripe/payment state, discount content, or the #99/#103 claimed files in this issue.

Explicitly out of scope

• Linking/unlinking/recovering an existing account (AUTH-004 — Link a Google identity to an existing Firebase member account #82).
• Authoritative membership lifecycle or migration (MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81 / AUTH-002).
• Members-only discount data/page (MEMBERS-CONTENT-001 — Build the Firebase-native members-only discounts page #83).
• Google Sites/Groups entitlement (GSITE-002 — Pilot Google Group access to the restricted member Site #84).
• Dues collection, race checkout, refunds, member pricing calculation, or payment state.
• Custom Google One Tap scripts, Drive/Sites/Groups scopes, provider-console mutation, or production rollout.

Claim protocol

Creation is not a claim. Do not edit implementation files until dependencies are complete, the issue is assigned, and a timestamped CLAIMED by <canonical agent> at <UTC>; branch <branch> comment is posted and re-read. Earliest valid claim wins.