Custom connector ignores configured request header, defaults to broken OAuth flow

### MCP server URL

https://programs-exceed-pair-circumstances.trycloudflare.com/mcp

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Static

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-07-19 4:45 AM EEST

### Browser and OS

Brave Portable (Chromium) + Microsoft Windows Version 25H2 (OS Build 26200.8655)

### Describe the issue

Custom connector with "Request headers" auth (x-api-key or Authorization: Bearer) never sends the configured header to the MCP server. Instead, claude.ai initiates an OAuth authorization_code flow against the server's origin, using the literal name of the configured header as the OAuth client_id. The server has no /authorize endpoint (it only supports static header auth), so the flow fails with a generic 401 unauthorized.

### Issue details

```shell
Steps taken:
1. Added custom connector with URL https://programs-exceed-pair-circumstances.trycloudflare.com/mcp
2. Set Request headers → x-api-key: (also tested Authorization: Bearer after removing and re-adding the connector, since editing an existing connector is not possible from the UI)
3. Clicked "Connect" both times

Result both times: redirected to
https://programs-exceed-pair-circumstances.trycloudflare.com/authorize?response_type=code&client_id=&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=...

client_id was literally "x-api-key" on the first attempt and "Authorization" on the second — matching whatever header name was configured. The tunnel origin has no /authorize route, so this returns {"error": "unauthorized"} from the server's generic 401 handler.

Verified server-side that the server itself works correctly: a direct curl request with the same header returns HTTP 200 with a valid mcp-session-id. No request with the configured header ever appears to reach the server through claude.ai's connection attempt.
```

### Expected behavior

claude.ai should send the configured request header directly on the initial POST to the MCP server URL, per the documented "Request headers" auth path for connectors without OAuth support — instead of attempting OAuth discovery/authorization_code flow.

### Logs from your server

```shell
2026-07-19T01:35:51Z INF Registered tunnel connection connIndex=0 connection=fafb65be-38e2-4c23-a6b4-b9b739966728 event=0 ip=2606:4700:a0::6 location=fra03 protocol=quic

Direct curl verification (server-side, bypassing claude.ai):
$ curl -s -D - -H "x-api-key: " https:///mcp -X POST -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","method":"initialize",...}'
HTTP/2 200
mcp-session-id: 3785b61f54b14fcca23a6556b2d9ab00

Unauthenticated request (no header) correctly returns:
HTTP/2 401
{"error": "unauthorized"}
```

### Additional context

No /.well-known/oauth-authorization-server or /.well-known/oauth-protected-resource metadata is served by the origin (confirmed via curl — both return the same generic 401), so there is no legitimate OAuth discovery signal that should have triggered this fallback behavior.