Bound kernel login token exchange with a timeout

[masnwilliams]

Summary

kernel login used a context with no deadline (signal.NotifyContext) and a default HTTP client with no timeout for the OAuth token exchange. When /token stalled (e.g. the auth server's Redis was unreachable), the browser showed the success page but the terminal spinner hung until the user hit Ctrl-C.

• Wrap the authorization-code exchange (exchangeCodeForTokens) in a 30s context deadline.
• Give the refresh request (RefreshTokens) an equivalent http.Client.Timeout.

Now a stalled auth server fails with a clear error in seconds instead of hanging the login. Companion to the kernel-mcp-server PR that stops the server side from hanging in the first place.

Test plan

• go build ./..., go vet, gofmt, go test ./pkg/auth/... all pass
• Manual: normal kernel login still completes against a healthy auth server (happy path unchanged)

---

Note

Low Risk
Small, defensive timeout wiring on existing OAuth HTTP calls; no change to token handling or security semantics beyond earlier failure on slow responses.

Overview
kernel login and token refresh no longer hang indefinitely when the auth server’s /token endpoint stalls (e.g. upstream Redis issues). The browser could already show success while the CLI spinner ran until Ctrl-C.

OAuth in pkg/auth/oauth.go now uses a shared 30s tokenExchangeTimeout: the authorization-code exchange wraps the caller context with context.WithTimeout before Config.Exchange, and RefreshTokens uses an http.Client with the same timeout instead of an unbounded default client.

^{Reviewed by Cursor Bugbot for commit 75a1057. Bugbot is set up for automated code reviews on this repo. Configure here.}