Refactor Authentication code in cuiman and wraptile

[TejasMorbagal]

They're not actually duplicating the same thing, they're two halves of the same thing

The important structural point: cuiman and wraptile implement different OAuth2 grant families.

Cuiman is a client acting on behalf of a human. It uses the password grant (ROPC), stores a refresh_token, persists auth config to disk, and refreshes reactively, the transport layer catches a 401, calls the refresher, retries once (transport/httpx.py:47-49).

Wraptile is a server acting as itself. It uses the client_credentials grant, has no user, no refresh token, no persistence, and refreshes proactively cache the token, re-mint 30s before expires_in lapses.
Both are legitimate. But the plumbing underneath them is duplicated, and each one implements the half of token lifecycle the other is missing.

A TODO item in cuiman is to move cuiman off ROPC to Device Code / PKCE, When we do that migration, we will want exactly what wraptile already has (expiry-aware caching) bolted onto exactly what cuiman already has (refresh-token grant). Right now those live in different packages, in different HTTP libraries, with different error types.

Proposed refactoring
gavicore is already a dependency of both cuiman and wraptile. we could extract a small gavicore.auth containing just the provider-agnostic OAuth2 plumbing:

• a TokenResponse model (access_token, refresh_token, expires_in)
• a token_request(url, grant_data) helper
• expiry-aware caching, lifted from wraptile's ClientCredentialsTokenProvider
• bearer-header construction