perf(core): load MCP client lazily - #42468

What

Keep the MCP SDK out of startup evaluation when a location has no enabled MCP servers. Configured enabled servers still connect eagerly during location service construction; disabled servers and installations without MCP defer the SDK until connect or OAuth authorization is actually used.

How

• packages/core/src/mcp/index.ts keeps MCPClient as a type-only import.
• The MCP client module loads immediately before the existing connect call.
• OAuth support loads only for authenticated remote connects or interactive authorization.
• Native ESM module caching deduplicates concurrent first imports; existing per-server locks, scopes, status transitions, reconnects, and finalizers are unchanged.
• packages/core/test/mcp-import-boundary.test.ts bundles the production entry and asserts that both runtime edges remain dynamic.

Impact

The flat workerd artifact remains one download, so its benefit is deferred evaluation rather than transfer size. In 20-process local measurements after importing mcp/index.ts, first client import averaged 77.31 ms; OAuth followed by client averaged 58.92 ms because the modules share SDK dependencies. That cost moves to the first enabled connect and is absent for no-MCP/disabled startup.

Scope

This does not make configured enabled servers connect on demand and does not change the MCP service API, config, protocol, server routes, connection policy, failure mapping, reconnect behavior, or shutdown behavior.

Testing

• bun run test in packages/core: 1,771 passed, 16 skipped
• bun typecheck in packages/core
• bun run test test/workerd.test.ts in packages/server
• bun typecheck in packages/server
• bun run probe:workerd in packages/server
• push hook: repository-wide bun turbo typecheck --concurrency=3, 35 tasks passed
• bun run lint packages/core/src/mcp/index.ts packages/core/test/mcp-import-boundary.test.ts: no errors; six pre-existing warnings in mcp/index.ts