[Bug] --chrome flag ineffective when resuming session — Chrome MCP stays disabled

Description

When resuming a session with claude --resume --chrome, the Chrome MCP server is not started. /chrome shows Status: Disabled. The --chrome flag is silently ignored on resume.

This is increasingly problematic as long-running sessions become the norm — users shouldn't have to abandon their session context just to get browser access back.

Steps to Reproduce

1. Start a session: claude --chrome (Chrome MCP works)
2. Exit the session
3. Resume: claude --resume --chrome
4. Run /chrome → Status: Disabled
5. Chrome MCP tools (mcp__claude-in-chrome__*) are unavailable

Expected Behavior

--chrome on resume should spawn a fresh Chrome MCP server, just like it does on a new session.

Actual Behavior

The --chrome flag is ignored. No chrome-native-host process is spawned. No bridge sockets are created. The MCP server is never started.

Environment

• OS: Ubuntu Linux (kernel 6.17)
• Claude Code: Latest (March 2026)
• Chrome: Installed with Claude extension and native messaging host configured
• Session type: Long-running (days to weeks, surviving multiple compactions)

Context

This is distinct from #25956 (WebSocket bridge death in long-lived sessions). That bug is about an active Chrome MCP connection dying mid-session. This bug is about the connection never being established on resume.

The combination makes Chrome MCP particularly fragile for long-running sessions:

1. If Chrome MCP dies mid-session (#25956) → can't recover without restart
2. If you resume with --chrome → flag is ignored, MCP never starts
3. Only workaround: completely new session (claude --chrome without --resume)

This forces users to choose between session continuity and browser access, which shouldn't be necessary.

Workaround

Start a completely new session (not resume) with claude --chrome. This loses the conversation context from the previous session.