Persistent Memory Leak in CredentialManager with LoginActivity

Description

We are experiencing a persistent memory leak in our Android application when using CredentialManager within a LoginActivity. The LoginActivity instance is being retained in memory
after it has been destroyed, as consistently reported by LeakCanary. The leak is always traced back to CredentialManager$GetCredentialTransport holding a reference to the activity's
context.

We have implemented several standard fixes for this type of leak, including using lifecycleScope for coroutines, implementing getCredentialAsync with a CancellationSignal that is
cancelled in onDestroy(), and ensuring that no strong references to the activity are held in callbacks. Unfortunately, none of these measures have resolved the issue. This leads us
to believe there may be an underlying bug in the androidx.credentials library.

Steps to Reproduce

1. Create a LoginActivity that uses CredentialManager.create(context) and credentialManager.getCredentialAsync(...).
2. Launch the LoginActivity.
3. Trigger the getCredentialAsync flow.
4. Close or navigate away from the activity.
5. Observe the memory leak reported by LeakCanary.

┬───
│ GC Root: Global variable in native code
│
├─ android.credentials.CredentialManager$GetCredentialTransport instance
│ Leaking: UNKNOWN
│ Retaining 658.5 kB in 6309 objects
│ mContext instance of in.aakhor.aakhorai.LoginActivity with mDestroyed = true
│ ↓ CredentialManager$GetCredentialTransport.mContext
│ ~~~~~~~~
╰→ in.aakhor.aakhorai.LoginActivity instance
Leaking: YES (ObjectWatcher was watching this because in.aakhor.aakhorai.LoginActivity received
Activity#onDestroy() callback and Activity#mDestroyed is true)
Retaining 656.9 kB in 6300 objects

Start with the LoginActivity reproduction using CredentialManager.create(context), getCredentialAsync, cancellation, and LeakCanary, then inspect the reported CredentialManager$GetCredentialTransport.mContext retention path. Done means confirming whether the leak is in the AndroidX Credentials library and documenting a reproducible diagnosis or validated fix; no repository file or test is named.

Written by the indexing model from the issue text.