OAuth completes fully (token_issued) but connector never becomes active — no MCP call after token

### MCP server URL

https://api.konexia.pro/api/v1/mcp

### Where does the issue occur?

When auth finishes and redirects back to Claude.ai

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### 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-09-10 2:19 PM -03 (Paraguay); server timestamp 2026-09-10T17:19:23Z

### Browser and OS

Chrome on macOS, claude.ai web (Customize > Connectors)

### Describe the issue

The OAuth 2.1 + DCR + PKCE flow completes successfully server-side every time (client_registered -> consent_granted -> token_issued, all HTTP 200/201), but Claude.ai then shows "Connection issue / Could not connect to the server" and the connector never becomes active. Our server never receives any authenticated POST /api/v1/mcp call after the token is issued. Reproduced 3 consecutive times with identical results (see server log excerpts below).

### Issue details

```shell
Error reference IDs shown in Claude.ai (3 separate attempts, same result each time): ofid_cd6e00924ee63268, ofid_1c197986dbd9c7b0, ofid_cf9e7f7c74de0641

Possibly related to #798, #699, #814 (other reports of claude.ai never completing the connector pipeline for a server that is independently confirmed healthy) — though our failure point differs: those report zero requests reaching their server at all, while ours completes register -> authorize -> token successfully and only fails silently after that.
Server-side evidence (our production backend access log, times UTC):

Attempt 3 (most recent):
17:19:17.004 POST /api/v1/mcp/oauth/register -> 201 Created
17:19:17.584 GET /api/v1/mcp/oauth/authorize?...redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback... -> 200 OK
17:19:22.294 POST /api/v1/mcp/oauth/authorize (user submits login) -> 302 Found
17:19:23.325 POST /api/v1/mcp/oauth/token -> 200 OK (access_token + refresh_token returned)
(nothing after this -- no POST /api/v1/mcp ever arrives)

This exact sequence (register -> authorize GET -> authorize POST 302 -> token 200 -> silence) repeated identically in attempts 1 and 2 as well, each ending with the same Claude.ai "Connection issue" toast a few seconds after the token endpoint returned 200.

We also independently confirmed our resource server correctly accepts the token once issued: a manual POST to /api/v1/mcp with a syntactically valid (but intentionally garbage) bearer token returns {"detail":"invalid_jwt_token"} rather than an auth-scheme error, i.e. our server is not rejecting the Authorization header format. We do not have access to a real issued token to test end-to-end ourselves (Claude.ai never logs/exposes it), so this is as far as we can verify server-side.

Server details:
- MCP endpoint: https://api.konexia.pro/api/v1/mcp
- OAuth metadata: https://api.konexia.pro/.well-known/oauth-protected-resource/api/v1/mcp (also served without the path suffix)
- redirect_uri used by Claude.ai: https://claude.ai/api/mcp/auth_callback
- Our authorization_server / issuer: https://api.konexia.pro
- Registration: Dynamic Client Registration (RFC 7591), token_endpoint_auth_method: none, PKCE S256 required
- Transport: streamable-http (single POST /api/v1/mcp endpoint)

We are the developers/maintainers of this MCP server and are available to provide additional server-side logs or a temporary read-only diagnostic endpoint if that would help triage.
```

### Expected behavior

After the token endpoint returns 200 with a valid access_token, claude.ai should call POST /api/v1/mcp with that Bearer token (initialize / tools list) and the connector should become active. Instead the UI immediately shows a generic connection-failure toast and no further request is ever made to our server.

### Logs from your server

```shell
2026-09-10T17:19:17.004Z POST /api/v1/mcp/oauth/register -> 201 Created
2026-09-10T17:19:17.584Z GET /api/v1/mcp/oauth/authorize?response_type=code&client_id=kx_client_HNMpYDQJZl2YPnhHafNe7UeJ&redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback&code_challenge=...&code_challenge_method=S256&scope=mcp%3Atools&resource=https%3A%2F%2Fapi.konexia.pro%2Fapi%2Fv1%2Fmcp -> 200 OK
2026-09-10T17:19:22.294Z POST /api/v1/mcp/oauth/authorize (login submitted) -> 302 Found
2026-09-10T17:19:23.325Z POST /api/v1/mcp/oauth/token -> 200 OK
(no further requests logged for this client_id / this connector)

Same shape reproduced twice more within the same session, ~5 and ~8 minutes earlier, different client_id each time (fresh DCR registration per attempt), identical ending at the token endpoint with silence afterward.
```

### Additional context

We independently confirmed our resource server correctly accepts the Bearer scheme once a token is issued: a manual POST to /api/v1/mcp with a syntactically valid (but intentionally garbage) bearer token returns {"detail":"invalid_jwt_token"} rather than any auth-scheme/header error — our server is not misbehaving on the resource-server side. We just never see claude.ai make that call with a real token. We are the developers of this MCP server and are happy to provide additional logs, our OAuth metadata documents, or a temporary diagnostic endpoint if that helps triage.