fix: serialize Grok token refresh to stop concurrent invalid_grant races

[moveeeax]

What

auth.Manager.refresh() claimed (via a stale comment) to serialize refreshes, but only held the mutex long enough to copy a few fields, releasing it before the actual HTTP round trip to the token endpoint. Concurrent callers hitting GetAccessToken right at token expiry would each read the same refresh_token and POST it to the provider at the same time.

Why it matters

Most OAuth providers rotate (single-use) refresh tokens: only the first of two concurrent uses of the same refresh_token succeeds, the second comes back invalid_grant. The goroutine that lost that race returned an error to its caller (token expired and refresh failed) even though a sibling goroutine had, moments earlier, successfully refreshed the credential the Manager now holds. Under any real concurrent load this shows up as spurious 503s from the proxy right at the token-expiry boundary, even though a valid token exists.

ForceRefresh (used after an upstream 401) had the identical gap — a burst of 401s across concurrent requests could each trigger a forced refresh concurrently.

How

• Added a dedicated refreshMu sync.Mutex held for the full duration of the refresh operation (network call + state update), not just the field copy.
• After acquiring it, a non-forced refresh re-checks whether the entry is already fresh — if a sibling call refreshed while this one waited for the lock, it returns immediately and the caller re-reads the now-current entry, instead of hitting the provider again with a token that may already be stale.
• ForceRefresh always attempts a refresh (correct — it's called specifically because the current token was rejected), but now goes through the same mutex so it can't stampede the token endpoint either.

Verification

gofmt -l .                                    → clean
go build ./...                                → ok
go vet ./...                                  → ok
go test ./... -race                           → ok (all packages)
go test ./internal/auth/... -run TestConcurrentGetAccessTokenDedupesRefresh -race -v -count=10
                                               → 10/10 PASS

New test TestConcurrentGetAccessTokenDedupesRefresh simulates a provider that rotates refresh tokens and fires 20 concurrent GetAccessToken calls right at expiry. Verified it fails reliably (5/5 runs) against the pre-fix code before restoring the fix.

Pre-existing, unrelated: go test ./... -count=3 panics in internal/config (pflag.CommandLine flag re-registration across repeated in-process runs) — reproduces identically on unmodified main, not touched by this change.