/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](https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-server-access)).
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`.

Written by the indexing model from the issue text.