feat: sign in with Google and GitHub from the hosted card

[joshpanka]

What

The hosted login and sign-up card offers "Continue with Google" and "Continue with GitHub" above the password form, the shape the password form keeps (visible, not disclosed). The identity service owns the round trip (its own PR); the card only starts it and shows the outcome.

• @bower/api: AuthProvider, the AUTH_PROVIDERS roster (label per provider), parseAuthProviders / authProviders() reading NEXT_PUBLIC_AUTH_PROVIDERS (a comma list inlined at build time like the origins; unknown names dropped, order kept, once each), providerStartUrl(provider, next) on the new authRoutes.socialStart (/social/<provider>/start, at the identity service's root like its other navigation targets), carrying the in-flight authorize so the identity service resumes it.
• @bower/ui: GoogleMark and GitHubMark, inline SVGs like the brand mark (lucide ships neither).
• (auth)/_components/provider-buttons.tsx: one full-width outline button per configured provider, each a full navigation to the identity service's start endpoint, then an "or" divider. CredentialsForm renders it above the form in both modes; the fallback skeleton reads the same provider list, so it cannot drift. With no provider configured the card is unchanged.
• (auth)/_components/provider-errors.ts: the identity service's ?auth_error= codes as one line each (account_exists, email_unverified, state_mismatch, provider_unavailable, provider_cancelled, provider_failed, rate_limited, account_inactive, a generic line for an unknown code), rendered as a banner at the top of the card, above the provider buttons the attempt came through (the form's own errors keep their slot inside the form). When the fix lives elsewhere the sentence's own verb is the link, so the banner stays one element in one color: email_unverified reads " hasn't verified your primary email. Verify it with , then try again." with the verb linking to that provider's email settings (GitHub's or Google's), the provider taken from the &provider= the identity service adds to its redirect, since either provider can report an unverified address; without it the line stays generic. ErrorMessage takes a ReactNode message for that. The login page reads the code on the server; the first submit replaces the arrival line with the form's own outcome.
• Config: .env.production sets google,github for the hosted worker; the dev compose passes NEXT_PUBLIC_AUTH_PROVIDERS through from the root .env (empty by default, documented in .env.example beside the local-hub block); the web image takes it as a build argument defaulting to none, since only an identity service holding provider credentials can honor a button.
• A self-hosted install's own login page (the hub button) is unchanged; its browser reaches the hosted card, which now shows the providers.

Verification

• pnpm -r lint, typecheck, test pass (the api package's 35: provider parsing for empty, one, both, an unknown dropped, a duplicate once; the start URL with and without next).
• On the dev stack against the local identity service: with NEXT_PUBLIC_AUTH_PROVIDERS unset, login and sign-up render no button and no divider; with google,github, both pages render the two buttons before the divider before the form, each linking to http://localhost:8001/social/<provider>/start?next=<the authorize>; /login?auth_error=account_exists paints "An account with this email already exists. Sign in with your password." and an unknown code the generic line; the self-host page still shows its one button.
• End to end with the identity service's branch running locally and no provider keys: its start endpoint bounces to /login?auth_error=provider_unavailable&next=... and the card shows "That way of signing in isn't available here." with the form beneath.