Salesforce Hosted MCP (Beta) — 'returned an error when connecting' after successful OAuth despite fully verified config

### Summary
"Salesforce - Beta" connector fails with a generic error immediately after a fully successful OAuth authorization, even with an External Client App config that has been verified correct end-to-end.

**Error shown in Claude:**
> Your account was authorized, but Salesforce - Beta returned an error when connecting. You can try again, or check that the server is working. If this persists, share this reference with support:

**Reference codes seen across repeated attempts:**
- `ofid_1a9c9d9071ec8cb6`
- `ofid_2597fd28e6a9c79c`

### Confirmation the OAuth flow completes on Salesforce's side
In Setup → External Client Apps → OAuth Usage, the app shows User Count: 1 with a green checkmark under OAuth Status immediately after each failed attempt — i.e. Salesforce issues a valid token every time, but the connection still fails on Claude's side afterward. This matches the "auth state synchronization lag" root cause Anthropic support described in #171.

### Config verified correct (ruled out as the cause)
- Require secret for Web Server Flow: **off**
- Require Proof Key for Code Exchange (PKCE): **on**
- Issue JWT-based access tokens for named users: **on**
- IP Relaxation: tried both "Enforce IP restrictions" and "Relax IP restrictions" — no difference
- Callback URL: `https://claude.ai/api/mcp/auth_callback`
- OAuth Scopes: `Access Salesforce hosted MCP servers (mcp_api)`, `Perform requests at any time (refresh_token, offline_access)`
- Target MCP server (`SObject All`) shows Server Status: Active in Setup → Integrations → API Catalog → MCP Servers
- App Status: Enabled, Permitted Users: All users can self-authorize

### Client
Claude (web / Cowork), connecting via the "Salesforce - Beta" connector.

### Related issues
This looks like the same bug reported in #171, #184, #280, and #420 — all show the identical pattern (token issued successfully per Salesforce logs, Claude fails right after with a fresh `ofid_`) and all remain open or were closed as "not planned" without a fix. Filing this as another data point with a fully-verified-correct config, in case it helps narrow down the root cause on Claude's side. Possibly related to #515 too (same error signature), though that report was on a Developer Edition org — this one is a production Enterprise org, so may point to a broader root cause than just DE org support.

### Question
Is this confirmed to be the same "auth state synchronization lag" issue tracked in #171? Is there a workaround, or an ETA for a fix?