Feature: Cross-interface MCP tool profiles and shared registry

Problem

Claude runs across multiple interfaces (VS Code Claude Code, CLI Claude Code, Desktop, mobile claude.ai). Each independently loads MCP tool schemas. ToolSearch (shipped) solves the context bloat problem within a single interface, but three gaps remain:

1. No shared tool registry -- each interface has independent MCP config. Adding a new MCP server means updating 3-4 config files.

1. No tool profiles -- cannot switch between "research mode" (Context7, WebSearch, Memory) and "coding mode" (GitHub, Bash, filesystem) tool sets without manual config edits. Related: #24000, #3206.

1. No dynamic unloading -- once a deferred tool is loaded via ToolSearch, it stays in context until session end. Long sessions accumulate tools that were needed once but consume context for the rest of the session.

Proposed Solution

Shared tool registry

A single ~/.claude/mcp-registry.json (or equivalent) that all Claude interfaces read. Each interface loads only what is relevant to its capabilities. Changes propagate to all interfaces.

Tool profiles

Named profiles that define tool subsets, activated via /profile research or auto-detected from project .mcp.json.

Dynamic unloading

Tools loaded via ToolSearch that have not been used for N turns are returned to deferred state, freeing context for active work.

Context

• ToolSearch (#11364, #12836, #23508) solved upfront loading -- this is about the remaining coordination and lifecycle gaps
• #17668 (MCP Context Isolation) is the closest related issue but focuses on agent-scoped isolation, not cross-interface sharing
• Community gateway ecosystem (IBM ContextForge, AgentGateway, lazy-mcp) shows demand but no solution covers the cross-interface case