fix(opencode): reconnect closed remote MCP clients

[rekram1-node]

Summary

• reconnect remote MCP clients after an owned transport onclose while retaining the existing public failed status
• use one reconnect path per server with bounded exponential backoff and generation, replacement, disconnect, and disposal fencing
• publish a replacement only after initialization and tool catalog discovery complete
• do not retry or replay failed tool calls; preserve the SDK patch's narrow session-bound 404 retry

Related issues

• Closes MCP remote client has no transport-level retry on socket/connection errors #25287
• Related to [FEATURE]: Full MCP client capabilities #28567
• Related to fix(mcp): MCP server loses connection mid-session causing intermittent failures #23997
• Related to MCP streamable-HTTP transport: 'Session not found' from server permanently breaks tool calls (no auto-reconnect) #25137
• Related to Bug: MCP tools permanently lost mid-session after single transient listTools() failure — no retry, no reconnect #17099
• Related to MCP server connection lost after context compaction — tools unavailable until new session #23556

Tests

• bun test test/mcp/reconnect.test.ts --timeout 30000
• bun test test/mcp/lifecycle.test.ts --timeout 30000
• bun test test/mcp/session-recovery.test.ts --timeout 30000
• bun typecheck in packages/opencode (run once during implementation; not repeated after the resource constraint update)
• bunx prettier --check src/mcp/index.ts test/mcp/reconnect.test.ts test/fixture/mcp-reconnect-server.ts

The new tests use a real loopback MCP endpoint in a child process with IPC/HTTP readiness signals, no mocks or fixed sleeps. They prove a single replacement initialization, no replay of an ambiguously failed call, a later request using the replacement, and intentional disconnect fencing a late reconnect.

Residual design

This first PR intentionally reacts only to definitive onclose and does not classify arbitrary request errors or replay requests. Ambiguous tool failures remain failures; recovery is available to future requests after the transport definitively closes.