[FEATURE]: MCP server startup timeout should fallback to lazy-load, not fail #13672

Problem

When an MCP server exceeds startup_timeout_sec (default 10s), OpenCode marks it as FAILED and its tools become unavailable for the entire session:

⚠ MCP client for `relace_id_VI4FGW` timed out after 10 seconds.
⚠ MCP startup incomplete (failed: relace_id_VI4FGW)

A server that takes 12 seconds isn't broken — it's just slow. Treating a timeout as a hard failure is a false negative that blocks users from tools that would work fine moments later.

Common causes of slow MCP startup

• uvx-based servers have variable cold-start times (3–15s) depending on package cache state
• Remote MCP servers depend on network latency
• Wrapper scripts that parse config or set up environments add overhead
• Multiple servers starting concurrently compete for CPU/network during the first 10 seconds

Proposed behavior

When an MCP server exceeds the startup timeout:

1. Promote to lazy-loaded state instead of marking as failed
2. Continue initialization in the background — don't kill the process
3. Log an info-level notice (not a warning/error):
   ℹ relace is still starting, tools will be available when ready
4. Make tools available as soon as the server finishes its MCP handshake
5. Only mark as FAILED if the server process actually exits or crashes

Current flow

Server slow → 10s timeout → ⚠ ERROR → server marked FAILED → tools unavailable

Proposed flow

Server slow → timeout threshold → ℹ "still starting..." → background init continues → tools available when ready

Prior art

Claude Code handles this well with its deferred tool loading mechanism — MCP servers register their tool manifests lazily, and tools are loaded on demand. There's no startup race condition.

Environment

• OpenCode v1.2.1
• macOS (Darwin 24.6.0, ARM64)
• Server that triggered this: relace-mcp via uvx (startup time ~7s warm, 12s+ cold)