feat(auth): add secure Google and GitHub sign-in with explicit account linking

[parthrohit22]

Summary

Add Google and GitHub as supported sign-in methods across the backend and frontend. The current product supports email/password only; the Iteration 1 design includes social sign-in controls, but they were intentionally omitted because no real backend contract exists.

This issue is separate from #220: #220 connects private GitHub repositories through a read-only GitHub App. This issue authenticates a PARTHA user. Authentication credentials, OAuth applications, scopes, and stored records must not be shared between the two concerns.

Current behavior

• Backend auth exposes /auth/register, /auth/login, /auth/refresh, /auth/logout, and /auth/me.
• A user has an email and an optional password hash; there is no external-identity model.
• Login and registration pages expose only real email/password controls.
• Adding decorative Google/GitHub buttons without this contract would create fake functionality.

Proposed scope

Backend

• Add a provider-identity model keyed by (provider, provider_subject), linked to one PARTHA user through a new Alembic migration.
• Implement Authorization Code flow with PKCE where supported, cryptographically random state, OIDC nonce for Google, strict redirect-URI allowlisting, and short-lived flow state.
• Support Google and GitHub initiation/callback endpoints that finish in the existing PARTHA access-token plus HttpOnly refresh-cookie session.
• Require verified provider identity data. Do not silently merge accounts by email.
• For an email that already belongs to a PARTHA account, require explicit authenticated linking or password confirmation before linking.
• Allow a signed-in user to link and unlink providers, while preventing removal of the final usable credential.
• Never store provider access tokens unless an explicitly documented feature requires them. If temporary tokens are required during callback handling, do not log or return them.
• Keep the seed/system user ineligible for interactive authentication.

Frontend

• Add working “Continue with Google” and “Continue with GitHub” controls to login and registration.
• Render a provider control only when the backend reports that provider as configured; otherwise omit it or show an honest unavailable state.
• Handle cancellation, denied consent, state mismatch, duplicate identity, and link-required outcomes in plain language.
• Add linked-account management under Settings → General.
• Preserve the current email/password flow and auth guard.

Acceptance criteria

• Google sign-in creates or authenticates the correct PARTHA user and starts the existing secure session.
• GitHub sign-in creates or authenticates the correct PARTHA user and starts the existing secure session.
• OAuth/OIDC state, PKCE, nonce, redirect allowlisting, and replay/expiry failure paths are covered by backend tests.
• A matching email never causes silent account linking or account takeover.
• Authenticated linking/unlinking is explicit, audited, owner-scoped, and cannot remove the final credential.
• Provider tokens, authorization codes, client secrets, and PARTHA tokens never appear in URLs after callback completion, application logs, or API responses.
• The frontend shows only configured providers and covers success, cancellation, provider error, and link-required states.
• Email/password login, refresh rotation/reuse detection, logout, and guarded routes continue to pass.
• OpenAPI, backend tests, frontend tests, accessibility checks, lint, production build, and Compose auth smoke checks pass.

Security and data considerations

Treat this as an authentication-boundary change. Threat-model login CSRF, account linking, email trust, replay, redirect manipulation, token leakage, provider outage, and credential removal. Any new dependency requires maintainer approval.

Non-goals

• Private-repository installation/import; that remains feat: read-only private GitHub App connector for design-partner onboarding #220.
• GitHub write scopes, repository scopes, organisation membership sync, SAML, or SCIM.
• Replacing the existing PARTHA refresh-token/session model.

Roadmap alignment

Advances roadmap §23 W6 (Identity & Access: OIDC and secure credentials) toward §28 deployment-specific security gates, while reducing onboarding friction for the real-engineer testing workflow. Merge evidence must include the threat model, negative auth tests, and completed end-to-end sign-in journeys.

[parthrohit22]

Implemented the credentials-deferred path this issue itself suggests, merged in #373. Confirming the invite-gate question explicitly, since it's the one thing that actually matters for whether this is safe to have live at all right now.

Confirmed: OAuth cannot be used to get API access without an approved invite

This isn't just the current default — it's the enforced, verified behavior:

• AuthService.register() is the only place in the entire backend that constructs a new User row, and it unconditionally requires a redeemed, unused invite code (checked directly against grep -rn "User(id=" app/ on the merged code — one call site, in register()).
• OAuthService never constructs a User. Every OAuth code path that ends in a live session (_complete_login's existing-identity match, _complete_link, confirm_pending_link) does so against a User row it already looked up by id or email — never a new one.
• A brand-new Google/GitHub identity with no matching existing account gets error_code: signup_requires_invite and is sent back to the real, invite-gated /register form — not auto-registered, not given a session, nothing created server-side.
• An identity whose email happens to match an existing account still requires that account's real password before linking (OAuthPendingLink + confirm_pending_link) — never a silent merge, and that existing account was itself only ever created through the invite-gated path above.

So: no invite code redeemed → no User row → no session, full stop, regardless of which door (password or OAuth) someone comes through. Backend test coverage for this exact guarantee: test_brand_new_identity_is_rejected_never_bypassing_the_invite_gate (service-level) and test_brand_new_identity_redirects_to_signup_required (HTTP-level), both in the merged PR.

What's built

• Full Google (PKCE + OIDC, id_token verified against Google's JWKS) and GitHub (code exchange + /user//user/emails) sign-in and account-linking.
• Explicit-confirmation linking — an email match alone never auto-links.
• Unlink, with a guard against removing an account's only credential.
• 54 backend tests (SQLite + real Postgres) and 21 frontend tests, all against clearly-fake mocked provider clients — no real OAuth app registered anywhere.

What's still needed before this can actually go live

• Real Google and GitHub OAuth application registration.
• Real GOOGLE_OAUTH_CLIENT_ID/_SECRET, GITHUB_OAUTH_CLIENT_ID/_SECRET, and OAUTH_PUBLIC_BASE_URL in deployment config.

Leaving this open until those are in place.