MCP OAuth refresh token flow is broken

[cstns]

Description

Third party MCP agents authenticate with a 30 minute access token and a 30 day refresh token stored on the same AccessToken row. A few things around refreshing them need attention.

Nightly cleanup deletes active grants (witnessed in real use)
The daily expireTokens housekeeper task deletes every token whose expiresAt has passed, without checking refreshTokenExpiresAt. MCP access tokens expire every 30 minutes, so the sweep removes grants that are still refreshable. The agent's next refresh fails with "Invalid refresh_token" and the token vanishes from the UI.
Fix: only delete rows where the refresh token is also expired or missing, the same guard getOrExpire already has.

Missing refresh_token returns a 500
A token request with grant_type=refresh_token and no refresh_token hits sha256(undefined) and throws.
Fix: validate the field and return 400 invalid_request, like the authorization_code branch does.

Refresh cache is per process
Concurrent refresh dedup uses an in-memory cache. With multiple replicas each one mints its own access token and overwrites the same row, so a token handed out by another replica stops working until the next refresh.
Fix: might be worth a shared cache, or dropping the dedup entirely.

Cached refreshes don't extend the window
A refresh served from the cache skips the refreshTokenExpiresAt bump, so the sliding window only extends on some refreshes.
Fix: bump it on every refresh.

MCP tokens look like PATs in the UI
They're stored with ownerType: 'user' and a name, so they show up in the Personal Access Tokens list with the 30 minute access expiry. That already misled a user into thinking his MCP access dies every half hour. Editing one there rewrites expiresAt but never refreshTokenExpiresAt, and clearing the expiry makes the token never expire.
Fix: show the real grant lifetime for MCP tokens or move them out of the PAT list, and keep the PAT edit path away from them.

[cstns]

Re: "Refresh cache is per process", parking this one for now.

The failure only shows up on multi-replica deployments when two refreshes for the same grant race each other. In practice OAuth clients serialize their token refreshes, and even when it does happen the damage is one 401 which the agent recovers from on its next refresh. So it's a self-healing edge case, not something users are hitting.

Meanwhile every proper fix is disproportionately heavy. A shared cache means new infrastructure on every deployment target and plaintext access tokens sitting in a shared store, which is worse than the hashed-at-rest posture we have everywhere else. Restructuring to a grant row with independent short-lived access tokens is the architecturally correct shape but real surgery. A previous-token grace slot on the row is the lightest option and still means a schema change on the shared AccessTokens table.

None of that is worth the risk for a problem we haven't actually observed in the wild. Leaving it documented here, and we'll pick it up if we ever see agents stuck in 401 loops on multi-replica installs.

Worth noting the "cached refreshes skip the sliding window bump" item lives in the same code path, so whichever fix we eventually pick should take both out together.