Transient body stream read errors misclassified as permanent via !e.is_decode()

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

Across multiple credential providers in `google-cloud-auth`, errors encountered while consuming HTTP response bodies are classified using `let retryable = !e.is_decode()`:
- `src/auth/src/mds/client.rs:236, 280, 302, 342`
- `src/auth/src/credentials/user_account.rs:479`
- `src/auth/src/credentials/impersonated.rs:1026`
- `src/auth/src/credentials/idtoken/impersonated.rs:509`
- `src/auth/src/credentials/idtoken/service_account.rs:150`
- `src/auth/src/credentials/internal/jwk_client.rs:116`

For example:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/auth/src/credentials/impersonated.rs#L1022-L1028

In `reqwest`, `response.json()`, `response.text()`, and `response.bytes()` map any transport error or connection reset that occurs during body streaming to `Kind::Decode` (`e.is_decode() == true`).

Because `retryable` is set to `false`, transport hiccups during body streaming are misclassified as permanent errors, causing `refresh_task` in `token_cache.rs:121-132` to terminate permanently.

Start by verifying the reported reqwest body-streaming behavior against the credential-provider call sites listed in src/auth/src/mds/client.rs, the credentials files, and src/auth/src/credentials/internal/jwk_client.rs. Then trace refresh_task in token_cache.rs:121-132 and existing error-handling tests or patterns. Done means transient response-body transport failures are retried rather than treated as permanent, without changing permanent decode-error handling.

Written by the indexing model from the issue text.