GCP: ClientOptions default_headers (Accept-Encoding) break OAuth token fetch

**Describe the bug**

`ClientOptions::client()` applies user `default_headers` (`src/client/mod.rs:843`) and also sets `.no_gzip()...` (`mod.rs:929`). The GCP token providers reuse that same client (`src/gcp/builder.rs:606-608`). So a data-plane `Accept-Encoding: gzip` header leaks onto the OAuth token POST (`src/gcp/credential.rs:613-637`, `accounts.google.com/o/oauth2/token`); Google returns gzip, `no_gzip` skips decoding, and `.json()` fails → `Error::TokenResponseBody`. The client tells the server "send gzip" while telling reqwest "don't decode gzip".

**To Reproduce**

```rust
let mut h = http::HeaderMap::new();
h.insert("accept-encoding", "gzip".parse().unwrap());
let store = GoogleCloudStorageBuilder::from_env()
.with_bucket_name("my-bucket")
.with_client_options(ClientOptions::new().with_default_headers(h))
.build()?;
store.get(&"x".into()).await?; // authorized_user ADC: token fetch fails before the GET
```

Error: `Generic { store: "GCS", source: TokenResponseBody(... "expected value at line 1 column 1") }`.
(`Accept-Encoding: gzip` is legitimate: it makes GCS serve `Content-Encoding: gzip` objects as raw gzip.)

**Expected behavior**

Setting `default_headers` for the data plane should not break authentication.

**Additional context**

Start with ClientOptions::client() in src/client/mod.rs at lines 843 and 929, then trace the shared client from src/gcp/builder.rs:606-608 into the token request in src/gcp/credential.rs:613-637. Use the provided authorized_user ADC reproduction to verify that the OAuth token fetch succeeds with a data-plane Accept-Encoding header while GCS object requests retain the intended behavior.

Written by the indexing model from the issue text.