n8n connector fails after successful OAuth: "n8n returned an error connecting" (Bearer token not attached to MCP requests)

### What happened?

I connected the n8n connector (self-hosted n8n, MCP instance-level access, v2.36.9) to Claude.ai/Cowork. The OAuth authorization completes successfully — n8n's own "Connected clients" page (Settings > Instance-level MCP) shows Claude registered with "Full access". However, immediately after, Claude.ai shows:

"Tu cuenta fue autorizada, pero n8n devolvió un error al conectarse. Puedes intentarlo de nuevo o verificar que el servidor esté funcionando correctamente."

This has happened on 3 separate connection attempts, each producing a distinct ofid_ reference (listed below).

I ruled out infrastructure causes before reporting:
- Confirmed via curl that the MCP endpoint (https://n8n.arismendizsystems.com/mcp-server/http) is publicly reachable and n8n itself responds correctly: {"message":"Unauthorized: Authorization header not sent"} for an unauthenticated request — proving the server is up and correctly implementing its own auth check.
- The instance sits behind Cloudflare Zero Trust/Access. I initially had an Access policy blocking the /mcp-server/* path; I added a Bypass policy scoped to that path and confirmed (via the curl test above) that Cloudflare is no longer intercepting the request.
- A different MCP client (Codex CLI, using a Cloudflare Access Service Token policy) connects to the same n8n instance without any issue, confirming the server side works correctly for other clients.

This matches a report in the n8n community forum where Anthropic support reportedly confirmed a bug where the OAuth handshake completes but the Bearer token is never attached to subsequent MCP requests: https://community.n8n.io/t/claude-ai-mcp-connector-failing-to-connect-to-my-self-hosted-n8n/280766/16

### What did you expect to happen?

Given that n8n's Connected Clients page shows the OAuth handshake completed successfully with Full access, I expected the connector to finish connecting and n8n's MCP tools to become available in the Claude.ai/Cowork chat.

### Steps to reproduce

1. Self-host n8n (v2.36.9) with Instance-level MCP enabled, and at least one workflow exposed to MCP.
2. Confirm the MCP endpoint (https:///mcp-server/http) is publicly reachable (no reverse proxy/Access blocking — verified with curl).
3. In Claude.ai (or a Cowork session), open connector settings and connect the n8n connector, completing the OAuth authorization flow in the browser.
4. Confirm in n8n (Settings > Instance-level MCP > Connected clients) that the client now shows as connected with Full access.
5. Claude.ai immediately returns: "Tu cuenta fue autorizada, pero n8n devolvió un error al conectarse..." with a new ofid_ reference.
6. Retrying produces the same error with a different ofid_ each time.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

n8n (self-hosted, Instance-level MCP, v2.36.9)

### Error messages or logs

```shell
"Tu cuenta fue autorizada, pero n8n devolvió un error al conectarse. Puedes intentarlo de nuevo o verificar que el servidor esté funcionando correctamente. Si esto persiste, comparte esta referencia con el soporte:"

ofid_0dbdc3e64064bd4f
ofid_ebd302f604fc265a
ofid_7882761fa6f5b3a6
```

### Additional context

n8n instance is behind Cloudflare Zero Trust (Access). Added a Bypass Access policy scoped specifically to the /mcp-server/* path to rule out Access blocking the request — confirmed working via curl (n8n responds directly, no Cloudflare redirect). A separate MCP client (Codex CLI) connects successfully to the same n8n instance via a Cloudflare Access Service Token policy, so the server-side setup is confirmed functional for other clients.