MCP servers should survive /clear and /compact

Feature Request

Problem

All MCP servers die when the user runs /clear or /exit. They must be manually reconnected by calling any tool from that server (lazy-reload). This is especially painful for MCP servers that maintain persistent connections or are used across every session (e.g., Notion, database connectors).

Impact

• Notion MCP: Used for async communication (chalkboard), task tracking, and content generation. After /clear, the first Notion call fails, then lazy-reload kicks in — but the failed call wastes a turn and confuses the agent
• Perplexity MCP: Used for research with cited sources. After /clear, falls back to the weaker built-in WebSearch
• Database MCPs (DuckDB, etc.): Lose connection state and query context

Users doing long sessions /clear frequently (every 30-60 min) to manage context. Each time, all MCP servers drop and must be individually reconnected.

Proposed Solution

MCP servers should persist across /clear and /compact operations. These commands reset the conversation context, not the session infrastructure.

Specifically:

1. /clear should only reset conversation history, not kill MCP server processes
2. /compact already preserves MCP connections (good!) — /clear should match this behavior
3. /exit killing MCPs is acceptable since it's a full session termination

Current Workaround

• CLAUDE.md instructs the agent to immediately call an MCP tool after /clear to force lazy-reload
• Users add SessionStart hooks to attempt reconnection
• Notion content is written to local .md files as fallback when MCP is unavailable

Additional Context

• Filed alongside #32062 (auto-save state before compaction)
• The lazy-reload mechanism works — the issue is just that servers are killed unnecessarily on /clear
• This affects ALL configured MCP servers, not just specific ones