fix(auth,client): cover token refresh with tests and repair the MCP 401 retry

[tim-thacker-nullify]

Follow-up to #164. login.go had no tests, so refreshToken was broken from February until #164 and nothing caught it. The MCP transport's 401 retry resolved its replacement token via GetValidToken, which only refreshes once ExpiresAt has elapsed — a revoked token returned the same string, so the retry never fired.

Changes

• internal/auth/login_test.go (new): refreshToken cookie/body/expiry paths, GetValidToken's expiry branch, ForceRefreshToken.
• authBaseURL is now a package var so tests can point the three auth calls at an httptest server. No behaviour change.
• auth.ForceRefreshToken refreshes regardless of stored expiry; ErrNotRefreshable when no refresh token is stored.
• lib.RefreshNullifyToken walks GetNullifyToken's precedence chain but insists on a fresh token. --nullify-token and NULLIFY_TOKEN are fixed strings, so they report client.ErrTokenNotRefreshable.
• refreshingAuthTransport takes a distinct refreshProvider for its 401 retry.
• 30s backoff after a failed refresh. cachedAt was untouched on failure, so past the TTL every request re-entered the write-locked path for another 30s-timeout refresh.
• Cookie loop skips empty access_token values and honours Expires when Max-Age is absent. Neither is reachable today; such a cookie would otherwise store expiresAt = now.
• A forced refresh that makes no progress -- error, the same token back, or an empty one -- arms its own 30s backoff and leaves the cache alone. Otherwise every request against rejected credentials takes a blocking refresh under the write lock. Trade: an out-of-band nullify auth login heals a session within 30s, not on the next request.
• Corrected fix: read refreshed access token from Set-Cookie header #164's comment: RefreshTokenOutput has no token field, so the cookie is the sole source, not a fallback.

flowchart TD
    A["RoundTrip gets 401"] --> B["forceRefresh"]
    B --> C{"token source"}
    C -->|"--nullify-token / NULLIFY_TOKEN"| D["ErrTokenNotRefreshable<br/>surface the 401, no retry"]
    C -->|"GitHub Actions"| E["re-exchange PAT"]
    C -->|"stored credentials"| F["ForceRefreshToken<br/>ignores ExpiresAt"]
    E --> G["retry once with the new token"]
    F --> G

Loading

G was unreachable for stored credentials: forceRefresh called tokenProvider, which returns the rejected token unchanged while ExpiresAt is in the future. The Actions branch already re-exchanged the PAT and is unchanged here.

Evidence

Each regression test is mutation-proved — reverting the matching production line fails exactly that test: #164's cookie block, the empty-value skip, the Expires fallback, forceRefresh calling tokenProvider, and the backoff.

Adding accessToken to RefreshTokenOutput server-side was rejected: both SPAs call it with credentials: 'include', so it would expose an HttpOnly token to page scripts, and WhoAmIOutput is a type alias of it. A CLI-shaped /auth/cli/refresh is tracked separately.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[tim-thacker-nullify]

Two findings noted but deliberately left out of this PR:

• client.NewRefreshingNullifyClient has no callers anywhere, tests included. This PR widened its signature rather than deleting it. Deleting is right, but it is scope creep on a fix.
• The provider closures in cmd/cli/cmd/mcp.go capture the command context, not req.Context(), so a refresh taken under the write lock does not observe request cancellation. Pre-existing on the getToken path; fixing it means TokenProvider becomes func(context.Context) (string, error).