Login con Google vía Supabase Auth (versión futura)

[Zenxlk]

¿Qué problema resuelve esta funcionalidad?

Segunda opción de login con cuenta real, además de correo/contraseña
(ver issue aparte). Deprioritizado respecto a correo/contraseña por
tener más piezas de configuración — queda anotado acá con la
investigación ya hecha para no perderla cuando se retome.

Nada de esto toca cards_game_service — mismo motivo que el login
por correo: el backend valida cualquier JWT válido de Supabase por JWKS
sin importar el proveedor.

Solución propuesta

Opción recomendada: SDK nativo de Google + signInWithIdToken
(la que sugiere la propia documentación de Supabase para Flutter), no el
flujo de redirect por navegador — mejor UX, usa el selector de cuenta
nativo del sistema en vez de abrir un webview.

final googleSignIn = GoogleSignIn(
  clientId: iosClientId,       // solo hace falta si hay build de iOS
  serverClientId: webClientId, // obligatorio siempre
);
final googleUser = await googleSignIn.signIn();
final googleAuth = await googleUser!.authentication;

final response = await supabase.auth.signInWithIdToken(
  provider: OAuthProvider.google,
  idToken: googleAuth.idToken!,
  accessToken: googleAuth.accessToken!,
);

Credenciales de Google Cloud necesarias (verificado contra la doc
oficial de Supabase, no son las que suele asumirse):

• Web Client ID: obligatorio siempre — se usa como serverClientId
  en Flutter y es el mismo que se carga en Supabase (Authentication →
  Providers → Google). Se crea en Google Cloud Console → APIs & Services
  → Credentials → Create Credentials → OAuth client ID → tipo Web
  application → Authorized redirect URI:
  https://cdtawynrlakytruycejn.supabase.co/auth/v1/callback.
• iOS Client ID: solo si hay build de iOS.
• Android Client ID con SHA-1: contra lo que se suele asumir, no
  hace falta — según la documentación de Supabase, el login en Android
  funciona solo con el Web Client ID.
• Requiere configurar la pantalla de consentimiento OAuth del proyecto de
  Google Cloud (tipo External) si todavía no existe.

Igual que en el login por correo, conviene vincular la sesión anónima
existente (updateUser/linkIdentity según corresponda) en vez de
reemplazarla, para no perder el historial ya asociado al playerId
anónimo.

Fase del proyecto a la que pertenece

• Futuro — Bots / modo online

Alternativas consideradas

Flujo de redirect (signInWithOAuth + deep link) — más simple de
configurar (un solo client ID, sin SDK nativo), pero peor experiencia
por el salto al navegador. Descartado a favor del SDK nativo.