fix(auth): clear provider sessions on sign-out without linking the Facebook SDK

[demolaf]

FirebaseAuthUI.signOut() never cleared the provider-side session. Both provider logout helpers ran after auth.signOut() had already cleared currentUser, and their guard tested FirebaseUser.providerId, which the SDK always reports as "firebase", so neither ever executed. A Google user's saved credential state survived sign-out, silently re-selecting the same account on the next sign-in instead of showing the picker, and a Facebook user was never logged out.

signOut() now reads the linked providers from providerData before signing out of Firebase, then clears each provider's session from the call site. The Facebook branch is additionally gated on ProviderAvailability.IS_FACEBOOK_AVAILABLE, since facebook-login is compileOnly and providerData can carry facebook.com for an account linked on another platform. Both helpers lose their now-unreachable internal guard and unused auth parameter; signOutFromGoogle rethrows CancellationException instead of swallowing it.

Added two FirebaseAuthUITest cases and the first e2e coverage of FirebaseAuthUI.signOut(), verified to fail on the old code and pass with the fix. Three pre-existing tests stubbed mockUser.providerId to values the real SDK never returns, which is what hid the bug; those stubs are gone.

---

Maintainer note: Fixes internal CPRN-435

[gemini-code-assist]

Code Review

This pull request refactors the sign-out flow in FirebaseAuthUI to ensure that provider-side sessions (Google and Facebook) are cleared properly. Since auth.signOut() clears the current user, the linked providers are now captured from providerData beforehand. Additionally, the Facebook sign-out logic is guarded to handle cases where the Facebook SDK is not present at runtime. Feedback on these changes suggests avoiding catching Throwable in signOutFromFacebook to prevent swallowing critical JVM errors, recommending catching LinkageError and Exception separately instead.

[gemini-code-assist]

Catching Throwable is generally discouraged as it swallows critical JVM errors such as OutOfMemoryError, StackOverflowError, or ThreadDeath. Since the Facebook SDK is a compileOnly dependency, missing classes will throw a NoClassDefFoundError (which extends LinkageError). Catching LinkageError and Exception separately allows you to safely handle both the missing SDK scenario and any runtime exceptions without swallowing critical system errors.

    try {
        loginManagerProvider.logOut()
    } catch (e: LinkageError) {
        Log.e("FacebookAuthProvider", "Facebook SDK not available or mismatched", e)
    } catch (e: Exception) {
        Log.e("FacebookAuthProvider", "Error during Facebook sign out", e)
    }

[demolaf]

Done, narrowed to LinkageError plus Exception. That covers both compileOnly failure modes (absent SDK, version mismatch) without swallowing OutOfMemoryError and friends.