Migration to Credential Manager for Sign-in process

[DenBond7]

This PR migrates Google Sign-In from the deprecated Google Sign-In API to Credential Manager.

• Uses GetSignInWithGoogleOption for authentication.
• Uses AuthorizationClient separately for Gmail scope authorization.
• Uses the email extracted from GoogleIdTokenCredential.
• Restarts authentication safely after process recreation.
• Clears Credential Manager state during logout.
• Replaces background silentSignIn() calls with GoogleAuthUtil token retrieval, including invalid-token eviction and retry.
• Updates UI test mocks and adds AccountEntity tests.

close #2531

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities

[DenBond7]

Current changes cover only sign-in action for the UI interaction case. But still is no available way to get idToken silently. And many tests will be disabled after these changes. I prefer not to update this library yet. I will wait for more functionality.

[sosnovsky]

it looks like here we don't check if Gmail access was granted during authorization, causing creation of FlowCrypt account without Gmail access. It should be better to require Gmail access here, so app will function correctly.

[DenBond7]

Thanks for pointing this out. Currently, the authorization request contains only one non-sign-in scope: https://mail.google.com/. For a single non-sign-in scope, Google does not use granular consent—the user either grants or denies the entire request. Also, getAuthorizationResultFromIntent() returns a result only for successful authorization and throws an ApiException otherwise. Therefore, reaching continueAfterGoogleAuthorization() should currently imply that Gmail access was granted.

However, I agree that explicitly checking AuthorizationResult.grantedScopes would make this requirement clear and protect the flow if more scopes are added later. I’ll add this validation to both the no-resolution path and the activity-result path before continuing with account creation.

[sosnovsky]

all good now 👍