Non-4xx/5xx token-endpoint error responses panic via expect_err in from_http_response

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

In `src/auth/src/errors.rs`, `from_http_response` handles non-success responses:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/auth/src/errors.rs#L87-L90

The code calls `response.error_for_status_ref().expect_err(...)`. However, reqwest's `error_for_status_ref()` returns `Err` only for 4xx and 5xx status codes (`status.is_client_error() || status.is_server_error()`).

If the token endpoint returns a 1xx or 3xx status code (e.g. 300, 302, 304, 307), `error_for_status_ref()` returns `Ok(&response)`. The `.expect_err()` call then panics inside the token refresh background task. Multiple callers gate only on `!status.is_success()`:
- `user_account.rs:474`
- `internal/sts_exchange.rs:131`
- `internal/jwk_client.rs:108`
- `external_account_sources/url_sourced.rs:83`
- `aws_sourced.rs:300, 333`
- `idtoken/service_account.rs:142`

Start in src/auth/src/errors.rs at from_http_response and inspect how non-success statuses are converted. Trace the callers named in user_account.rs, internal/sts_exchange.rs, internal/jwk_client.rs, external_account_sources/url_sourced.rs, aws_sourced.rs, and idtoken/service_account.rs. Done means 1xx and 3xx token-endpoint responses no longer trigger a panic in the refresh path.

Written by the indexing model from the issue text.