feat(ios): GoogleSignInProviderIOS pasa a object — una sola forma desde Swift

[hgarciaalberto]

Implementa el spec 011. Cierra la causa que el spec 003 solo pudo parchear.

Sustituye a #22, que GitHub cerró automáticamente al borrarse su rama base
(feature/010-ios-build-hygiene) tras el merge de #21. Mismo trabajo, rebasado sobre develop.

El problema

GoogleSignInProviderIOS era el único de los seis providers de iOS con forma de class +
companion object, porque recibía GoogleSignInConfig en el constructor. Kotlin/Native exporta un
companion por su cuenta, así que el mismo seam tenía dos escrituras válidas en Swift. Las dos
compilan, y por eso nadie lo veía: no era un fallo, era ruido que enseñaba al lector que hay dos
contratos. El README llegó a usar las dos formas para el mismo objeto con 24 líneas de diferencia,
y de ahí salieron los ejemplos que no compilaban que arregló el 003.

El cambio

object, como los otros cinco. La config viaja en signIn(config), igual que
AppleSignInProviderIOS.signIn(scopes).

	1.x	2.0.0
Swift	GoogleSignInProviderIOS.Companion.shared.signInHandler = …	GoogleSignInProviderIOS.shared.signInHandler = …
Swift	GoogleSignInProviderIOS.Companion.shared.signOutHandler = …	GoogleSignInProviderIOS.shared.signOutHandler = …
Kotlin	GoogleSignInProviderIOS(config).signIn()	GoogleSignInProviderIOS.signIn(config)

Pasar a object no globaliza nada que no lo fuera ya: signInHandler, signOutHandler y el
callback pendiente vivían en el companion, o sea uno por proceso. La forma anterior solo sugería
lo contrario.

Verificación

El spec proponía un grep como criterio de AC-01. Se comprobó además en el header de
Objective-C del framework, que es lo que Swift ve de verdad:

• ComposeAppGoogleSignInProviderIOSCompanion pasa de existir a 0 apariciones
• ComposeAppGoogleSignInProviderIOS expone ahora
  @property (class, readonly, getter=shared), idéntico a los providers que ya eran object

ktlintCheck, :custom-login:testDebugUnitTest y :composeApp:linkDebugFrameworkIosSimulatorArm64
en verde en local.

La decisión abierta del spec, resuelta con datos

El spec dejaba abierto qué hacer con getClientId() y getTopViewController(), y dudaba por un
posible «consumidor Swift desconocido». Se pudo medir en vez de estimar: getClientId() tiene
cero call sites en toda la organización apptolast, y ni Fledge ni Paparcar nombran
GoogleSignInProviderIOS en Kotlin ni en Swift.

• getClientId() → eliminada. Quien pudiera llamarla ya tiene en la mano la GoogleSignInConfig de la que leía.
• getTopViewController() y onSignInResult() → se quedan con el @Deprecated que les puso el spec 010.

Dos cosas que salieron al verificar

• El KDoc de AppleSignInProviderIOS explicaba que .companion existe «para el companion object
  de una clase, como GoogleSignInProviderIOS». Con este cambio deja de ser cierto.
• CLAUDE.md documentaba :custom-login:linkDebugFrameworkIosSimulatorArm64, que no existe.
  La librería no declara binaries.framework propio — se exporta a través del ComposeApp del
  demo. Se descubrió al ejecutarlo. Corregidas las cuatro apariciones.

Compatibilidad

BREAKING para hosts Swift, pero falla en compilación, no en runtime: el host se entera al subir
el pin, no un mes después con un botón muerto.

Sale en 2.0.0, junto al renombrado custom-login → baselogin que viene detrás, para que los
consumidores migren una sola vez en lugar de dos. La versión la fija esa PR; aquí solo va la nota
en el README (Migrating to 2.0.0).

🤖 Generated with Claude Code