Route Copilot MCP Gallery installs through Agent Host
The Issue & Context
Before this PR, MCP Gallery installs for Copilot sessions were not routed through the Agent Host install provider, causing installation provenance loss and inconsistent handling of installs, updates, and uninstallations in Copilot sessions.
Root Cause Analysis
The existing MCP Gallery installation flow bypassed the Agent Host install provider and Copilot SDK's confirmed-installation flow, leading to missing linkage of the registry card URL as installation provenance and stale custom-registry entries not being rejected before provider invocation. This was due to separate handling paths for Copilot installs and other MCP installs in files like copilotCustomizationInstallations.ts and agentHostCustomizationMarketplaceInstallProvider.ts.
Solution Strategy & Architectural Pattern
This PR routes MCP Gallery installs for Copilot sessions through the Agent Host install provider and the Copilot SDK confirmed-installation flow, preserving the registry card URL as the installation provenance. It rejects stale custom-registry entries before provider invocation and maintains Gallery association across provider and window restarts. The changes span multiple files including copilotCustomizationInstallations.ts, agentHostCustomizationMarketplaceInstallProvider.ts, and mcpGalleryService.ts to unify and centralize the install, update, and uninstall logic under the Agent Host and SDK mechanisms while retaining VS Code MCP management for non-provider harnesses.
Key Takeaway for Contributors
When integrating third-party installation flows with platform SDKs, centralizing installation provenance and lifecycle management through a single provider avoids state inconsistencies and stale data, especially across process or window restarts.