Add a `token_provider` parameter to `Client.__init__()` so callers can
supply their own bearer-token callable (e.g. for M2M / service-account
flows) instead of relying on the built-in OAuth device-code flow.

The operation cache needs a token to build per-user cache keys. Three
approaches were explored:

1. **CachedApiMixin with Protocol** (explored, discarded) —
   A `_HasTokenProvider` Protocol plus `CachedApiMixin` base class that
   provided a `_cached()` convenience method. Saved one kwarg per call
   site but added multiple-inheritance, a Protocol, and competing `_api`
   annotations on every resource class. Over-engineering for what amounts
   to avoiding `token_provider=self._api.token_provider`.

2. **`TokenProvider` type alias** (explored, discarded) —
   `TokenProvider = Callable[[], str]` exported as public API. Added no
   value over the raw `Callable[[], str]` since every parameter is
   already named `token_provider`. Removed to avoid unnecessary imports
   and indirection.

3. **`_AuthenticatedApi` subclass + explicit `token_provider` at each
   call site** (chosen) — A thin `_AuthenticatedApi(PublicApi)` subclass
   in `_api.py` lifts `token_provider` from the deeply-nested codegen
   `Configuration` to a top-level attribute. Each cached method passes
   `token_provider=self._api.token_provider` to `@cached_operation(...)`.
   One kwarg of boilerplate per call site, but no new types, no
   inheritance, and trivially greppable. `_api.py` exists solely to
   break the circular import between `_client.py` and the resource
   modules.

…caching