fix(auth): fix "Already resumed" crash in phone auth SMS auto-verification

[demolaf]

Fixes #2446.

DefaultVerifier adapted Firebase's OnVerificationStateChangedCallbacks — which can fire more than once for a single request — onto a single-shot suspendCoroutine, resuming the same continuation from onVerificationCompleted, onVerificationFailed and onCodeSent. On the SMS auto-retrieval path Firebase delivers onCodeSent and then onVerificationCompleted, so the second resume threw IllegalStateException: Already resumed on the main thread inside Firebase's own dispatcher, where nothing in the library can catch it.

Verifier now returns a Flow built with callbackFlow, so several callbacks are simply several emissions and there is no continuation left to double-resume. A credential auto-retrieved after the code was sent now reaches AuthState.SMSAutoVerified rather than being discarded, so the user is no longer asked to type a code Firebase has already verified.

Because the collection stays open for the verification window instead of returning at onCodeSent, PhoneAuthScreen now cancels superseded attempts on send, resend, change-number and success, and skips auto sign-in while a manually submitted code is still signing in. Cancellation is not reported to the host as an error.

Added PhoneAuthDefaultVerifierTest and PhoneAuthScreenVerificationLifecycleTest, covering every callback ordering, the auto-retrieval timeout terminal, and the screen's cancellation and guard lifecycle — the multi-callback cases fail against the old code.

Preview

• Before

before-fix.mp4

• After

after-final.mp4

[demolaf]

/gemini review

[gemini-code-assist]

Code Review

This pull request improves phone number verification by handling coroutine cancellation and multiple callbacks more robustly. It transitions from suspendCoroutine to suspendCancellableCoroutine and introduces an AtomicBoolean to prevent multiple callbacks from resuming the continuation. Additionally, user-initiated cancellation now clears the pending loading state and propagates the CancellationException directly rather than emitting an error state. Comprehensive unit tests have been added to cover these scenarios. The review feedback suggests registering an invokeOnCancellation listener to mark the operation as resolved upon cancellation, which prevents late-arriving callbacks from attempting to resume the cancelled continuation.

[russellwheatley]

Crash is gone, but first-callback-wins still drops auto-retrieval on the path this PR is fixing.

[russellwheatley]

LGTM.