Offer re-consent when an extension's refresh token is rejected (invalid_grant)

[CaseyLabs]

Problem

If the refresh token for an extension OAuth slot (e.g. google-calendar) is rejected by the provider with invalid_grant, there is no way to recover from the UI.

This happens routinely with self-created Google OAuth clients (see #336): while the app is in Testing, Google expires refresh tokens after 7 days. Mail keeps working once re-authorized, but the calendar slot's token dies separately.

Repro:

1. Have a google-calendar token whose refresh token is expired/revoked.
2. Remove the Google calendar source (or have none).
3. Calendar → Add Google Calendar → pick the account.

Result: the dialog shows ... auth broker: refresh: token refresh failed: invalid_grant - Bad Request and no Grant Calendar Access button. That button (in AddGoogleCalendarDialog, AddMicrosoftCalendarDialog and both account hook panels) only appears when the error contains additional consent required, which the broker only raises when the token row is missing or lacks scopes, not when it exists but is dead. The per-source Reauthorize button in Calendar Settings doesn't help when there is no source. The only workaround is deleting the oauth_tokens row by hand.

Fix

• internal/oauth2: RefreshTokenWithProvider wraps invalid_grant responses in a new ErrInvalidGrant sentinel. The error message text is unchanged.
• internal/extensions/auth: when a refresh fails with ErrInvalidGrant, bearerRefreshTransport returns *coreapi.ErrAdditionalConsentRequired for that slot, with the scopes the client was issued for. The existing UI then offers the grant flow, and StartIncrementalConsent overwrites the dead token. The error carries a new optional Reason (refresh token expired or revoked), so its message no longer claims scopes are missing. It still starts with additional consent required, which is the text the calendar dialogs match.
• This only applies to slots an extension grant flow can re-grant: the *-calendar and *-contacts slots with credentials configured. A new oauth2.IncrementalConsentProvider makes that decision, and StartIncrementalConsent now uses the same function, so the two can't drift apart. Mail slots (custom-mail for bring-your-own-app accounts, and google-mail / microsoft-mail that Contacts uses for its read scopes) keep the original refresh error. Only mail re-authorization can replace those tokens, so a Grant button there would just fail again.

Other refresh failures (network errors, invalid_client, etc.) keep the existing error.

Tests

• TestRefreshTokenWithProvider_InvalidGrant / _OtherErrorIsNotInvalidGrant: sentinel matching against an httptest token endpoint.
• TestTransport_InvalidGrantOnMailSlotKeepsRefreshError: end to end through HTTPClientForExtension for a custom account, with stub API (401) and token (invalid_grant) servers. The custom-mail slot must return the ErrInvalidGrant refresh error, not a consent error.
• TestErrAdditionalConsentRequired_Error: the message with and without Reason.
• TestCanRegrant: which slots get the consent error. An extension slot with credentials does; an extension slot without credentials and the mail slots don't.

The calendar and contacts slots refresh against Google's and Microsoft's real token URLs, so there's no end-to-end test for the consent conversion itself; TestCanRegrant covers which slots qualify.

go test ./internal/... ./extensions/... passes, except TestSerializeVEVENT_AllDay. That test also fails on main when run outside UTC; it's unrelated to this change.

Notes

• Broker now builds every extension HTTP client through one newClient helper instead of three copies of the same setup. The helper copies the scopes list, so the client doesn't share the caller's slice.
• For a source that already exists, background sync now records additional consent required for account … under google-calendar: refresh token expired or revoked as its last_error instead of the raw invalid_grant text. The Reauthorize button was already shown for those sources.
• Nothing starts a consent flow automatically. Only the user-initiated dialogs react to this error.