refactor(cloudflare): migrate from Durable Objects to stateless MCP handler

[dcramer]

Replace McpAgent-based Durable Object pattern with experimental_createMcpHandler for a simpler, stateless architecture:

• Use AsyncLocalStorage for per-request constraint scoping instead of DO state
• Get auth context from getMcpAuthContext() set by OAuth provider
• Support dynamic context resolution via getContext() callback
• Remove Durable Object bindings and migrations from wrangler configs
• Update server.ts to support both static (stdio) and dynamic (HTTP) contexts

This eliminates the complexity of Durable Object lifecycle management while maintaining the same functionality for org/project constraint scoping.

[dcramer]

havent reviewed/verified yet

[sentry]

Bug: Successful chat responses do not close mcpClient, leading to unclosed StreamableHTTPClientTransport connections.
_{Severity: CRITICAL | Confidence: 1.00}

🔍 Detailed Analysis

The mcpClient is not closed on a successful response path because the cleanup code is only present in an outer catch block. When return response; is executed at line 363, the function exits, bypassing the cleanup logic. This leaves StreamableHTTPClientTransport connections open, leading to connection handle and memory leaks over time.

💡 Suggested Fix

Implement a finally block to ensure mcpClient.close() is called after processing, regardless of success or failure, similar to the pattern used in metadata.ts.

🤖 Prompt for AI Agent

Fix this bug. In packages/mcp-cloudflare/src/server/routes/chat.ts at line 363: The
`mcpClient` is not closed on a successful response path because the cleanup code is only
present in an outer `catch` block. When `return response;` is executed at line 363, the
function exits, bypassing the cleanup logic. This leaves `StreamableHTTPClientTransport`
connections open, leading to connection handle and memory leaks over time.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: During token refresh, the initial mcpClient is replaced without closing, causing a resource leak.
_{Severity: CRITICAL | Confidence: 1.00}

🔍 Detailed Analysis

When an authentication error occurs and a token refresh is attempted, a new mcpClient is created and assigned to the mcpClient variable at line 264. The original mcpClient instance, along with its underlying httpTransport, is not closed before being overwritten, causing its reference to be lost and leading to a resource leak.

💡 Suggested Fix

Ensure the initial mcpClient is closed before reassigning mcpClient to a new instance during the token refresh process.

🤖 Prompt for AI Agent

Fix this bug. In packages/mcp-cloudflare/src/server/routes/chat.ts at line 264: When an
authentication error occurs and a token refresh is attempted, a new `mcpClient` is
created and assigned to the `mcpClient` variable at line 264. The original `mcpClient`
instance, along with its underlying `httpTransport`, is not closed before being
overwritten, causing its reference to be lost and leading to a resource leak.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[dcramer]

Im going to ignore those mcpClient issues for now