/mcp search fails with 400 Bad Request in every repo with a non-GitHub (Azure DevOps) git remote

Describe the bug

/mcp search (interactive MCP registry browser) consistently fails with:

Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request

whenever Copilot CLI is started inside a trusted folder whose git remote points to Azure DevOps (dev.azure.com) instead of a GitHub-hosted remote. This affects our entire engineering org, since 100% of our repositories are hosted on Azure DevOps.

Environment

• Enterprise: GitHub Enterprise Cloud with data residency / EMU tenant
• OS: Windows
• Enterprise MCP Registry: configured and verified working (Azure API Center-backed registry, "Registry only" policy) — confirmed via direct curl calls that the registry itself returns HTTP 200 with the expected servers.

Workaround: Run /mcp search from a non-git folder to add servers once; they then work from any repo afterward via the persisted ~/.copilot/mcp-config.json.

Affected version

GitHub Copilot CLI 1.0.78

Steps to reproduce the behavior

1. Configure an enterprise MCP Registry URL + "Registry only" policy (per GitHub docs).
2. cd into any local git repository whose origin remote is an Azure DevOps URL (e.g. https://org@dev.azure.com/org/project/_git/repo).
3. Start copilot.
4. Run /mcp search.
5. Observe: Failed to load registry: Error: Failed to fetch MCP registry policy: 400 Bad Request.
6. cd outside any git repository (e.g. home directory) and start a fresh copilot process.
7. Run /mcp search again → succeeds, returns all registry servers.

Expected behavior

/mcp search should successfully fetch the registry policy regardless of the git remote host of the current working directory, or at minimum should not derive repo/org context from non-GitHub git remotes in a way that breaks the request.

Additional context

• The failure is tied to process startup cwd/git-remote context, not conversation state: /new inside the same running process does not recover it — only a full process relaunch outside a git-remote folder works.
• Once servers are added via the workaround below (outside a repo), they persist in ~/.copilot/mcp-config.json and connect fine from inside our Azure DevOps repos afterward — so the registry policy fetch specifically is what's broken, not general MCP connectivity.
• Reproduces consistently; not a timing/cache issue; not related to our enterprise's registry configuration (independently verified correct).

Start by reproducing /mcp search from a repository with an Azure DevOps remote and from a non-git folder, then trace the startup context used for the MCP registry policy fetch. The issue is done when registry search succeeds regardless of the current git remote, without breaking the existing persisted configuration in ~/.copilot/mcp-config.json.