Calendar connector "requires additional permissions" error persists after full revoke + reconnect — matches #424 pattern

### MCP server URL or name

Built-in Google Calendar connector (provided by Anthropic)

### How are you connecting to this server?

From browsing the MCP server directory

### Where does the issue occur?

During a conversation (after initial auth)

### When did you last reproduce this?

2026-07-19, multiple times over ~1 hour, Europe/Amsterdam time

### Browser and OS

Cowork (Claude desktop app)

### Describe the issue

Google Calendar connector (list_calendars, list_events) returns a permissions error on every call, and it does not clear no matter what re-auth steps are taken.

Steps taken, none resolved it:
1. Reconnected the connector from within Claude (settings showed it as connected with the correct permissions listed)
2. Retried tool calls — same error
3. Revoked app access at the Google account level (myaccount.google.com/permissions), then reconnected fresh from Claude
4. Retried tool calls — identical error, unchanged

Notes:
- The connector shows as fully connected in Claude's settings UI, with the right scopes listed — the failure is purely at the tool-call layer
- The Gmail connector on the same session/account is working normally, so this isn't an account-wide auth outage
- Behavior matches #424's description (fixed error, immune to re-auth/revoke) rather than the OAuth-scope-request bugs (#51424, #62556)

Filing as an additional data point for #424, since that issue's root cause (suspected corrupted server-side token/scope state) appears unresolved and this looks like the same failure class on a different connector/account.

### Error details

```shell
This connector requires additional permissions. The user needs to reconnect it with the appropriate access.

Exact string returned on every list_calendars / list_events call, before and after revoke + reconnect. No error ID surfaced in the Cowork UI for this failure.
```

### Expected behavior

Calendar tool calls should succeed with valid OAuth tokens and return normal data once the connector shows as connected with the correct scopes granted, as it does for other connectors (e.g. Gmail) on the same account/session.

### Additional context

Related: #424 (same failure class — fixed permission error immune to re-auth/revoke, on one connector/account while others work fine). Happy to provide timestamps or request IDs through a private channel if useful for triage.