autoConnect: lazy CDP connection causes consent timeout in MCP hosts with tool call timeouts

Problem

When using --autoConnect with Chrome's chrome://inspect/#remote-debugging toggle (Chrome 153, Windows), the MCP server initializes instantly but defers the actual Chrome CDP connection to the first tool call (e.g., list_pages).

This causes a deadlock when the MCP host (OpenCode, MCPProxy) enforces tool call timeouts (~60s):

1. list_pages called - triggers Connecting Puppeteer to {channel: chrome}
2. Chrome shows consent dialog ("Allow remote debugging?")
3. User clicks "Allow" but tool call already timed out
4. Host kills MCP process - consent grant lost
5. Next call - new process - new consent needed - repeat

Evidence from debug log

17:53:16 - Starting Chrome DevTools MCP Server v1.9.0 (PID 32600)
17:53:16 - Chrome DevTools MCP Server connected (stdio init - no Chrome connection)
17:54:17 - list_pages request: {}
17:54:17 - Connecting Puppeteer to  {defaultViewport:null, handleDevToolsAsPage:true, channel:chrome}
           ^^^^^^^^ HANGS HERE waiting for consent
~17:55:17 - Host kills process (stdin end)

Proposed Fix

Connect to Chrome during MCP init rather than lazily on first tool call. The init phase typically has a much longer timeout (3m+) than individual tool calls (60s), giving the user time to click the consent dialog.

Alternatively, expose a --connectTimeout option so hosts can configure how long to wait for the consent click.

Environment

• Chrome 153 (stable)
• chrome-devtools-mcp v1.9.0
• Windows 11
• MCP host: OpenCode (also reproduced via MCPProxy-Go v0.67.0)
• --autoConnect with chrome://inspect/#remote-debugging toggle enabled

Workaround

Using --browser-url with a dedicated Chrome profile launched via --remote-debugging-port and --user-data-dir bypasses the consent dialog entirely but requires a separate browser instance.