JwkClient uses try_write and holds write lock across network fetch

Unconfirmed. This is the result of a search with Claude, may be a false positive.

In `src/auth/src/credentials/internal/jwk_client.rs`, `get_or_load_cert` acquires the cache write lock using `try_write()`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/auth/src/credentials/internal/jwk_client.rs#L56-L78

Because `try_write()` is non-blocking, any lock contention causes concurrent callers to immediately fail with a non-retryable error (`"failed to obtain lock to read certificate cache"`).

Furthermore, the write lock guard `cache` is held across the asynchronous network call `self.fetch_certs(jwks_url).await?`. Any concurrent verification requests during key fetching will immediately fail, even if the requested key is already present in the cache.

Start in src/auth/src/credentials/internal/jwk_client.rs at get_or_load_cert and trace the cache lock through self.fetch_certs(jwks_url).await. Confirm the reported contention and lock lifetime, then verify that concurrent verification requests do not fail unnecessarily while certificates are fetched and that cached keys remain usable.

Written by the indexing model from the issue text.