Add `--disable-repo-mcps` flag to skip loading MCPs from `.mcp.json` / `.github/mcp-config.json`

### Describe the feature or problem you'd like to solve

Today there is **no clean way to launch `copilot` while ignoring the MCP definitions a repository ships in `./.mcp.json` or `.github/mcp-config.json`** — you can only disable MCPs at a per-name granularity via `--disable-mcp-server ` (repeatable), which requires knowing every name the repo defines and re-typing them on every launch.

This matters in a few real situations:

1. **A repo's MCP config silently shadows my user-level config.** See the related bug report ([#3379](https://github.com/github/copilot-cli/issues/3379)) where `.mcp.json` in a repo overrode my user-level playwright MCP (which was correctly configured with `--browser msedge`) with a default-browser version that tried to launch chrome. I couldn't fix this without:
- Editing `.mcp.json` (a shared tracked file in the repo — I shouldn't commit that change)
- Or temporarily renaming/moving it
- Or remembering to type `--disable-mcp-server playwright --disable-mcp-server --disable-mcp-server ...` every time I launch `copilot` in that repo.

None of these are reasonable workflows.

2. **The repo's MCP definitions require dependencies I don't have installed**, blocking the CLI from starting cleanly.

3. **I trust my own user-level MCP config but not necessarily the MCP servers a freshly-cloned repo brings in** (security/supply-chain consideration). Today the only mitigation is reviewing/editing every cloned repo's `.mcp.json` before first launch.

A prior CLI session also reached the same dead end while researching options — the closest workarounds we could find were:
- Launching from a different cwd (`copilot -C $HOME`) and then `/cwd`-ing in, which is awkward and fights the CLI's workspace-awareness.
- Wrapping `copilot` in a shell alias that hard-codes every repo MCP name to disable, which doesn't scale across repos.

### Proposed solution

Add a CLI flag (suggested name: `--disable-repo-mcps`) that prevents the CLI from loading MCP definitions from any repository-scoped config file. Only built-in MCPs and user-level MCPs (`$HOME/.copilot/mcp-config.json`) would be considered.

Example:

```
copilot --disable-repo-mcps
```

Additional refinements worth considering:

- **Persist as a session setting** the way `--experimental` does, so users who always want this behavior in certain environments can set it once.
- **Show repo MCPs as disabled in `/mcp`** with a note like `(skipped: --disable-repo-mcps)`, so it's discoverable.
- **Allow opt-in re-enablement of specific repo MCPs** via something like `--enable-mcp-server ` for symmetry with the existing `--disable-mcp-server `. (Optional; the headline flag alone covers most cases.)
- **Companion env var** (e.g., `COPILOT_DISABLE_REPO_MCPS=1`) for users who want it set per-shell without editing aliases.

### Example prompts or workflows

Workflow 1 — my user-level MCP setup is canonical and I never want repos to override it:

```
alias copilot='copilot --disable-repo-mcps'
```

...and now `cd`-ing into any cloned repo just works with my own MCP toolchain, ignoring whatever the repo happens to ship.

Workflow 2 — I want to quickly check what a repo defines without it actually loading:

```
cd some-repo
copilot --disable-repo-mcps
/mcp # shows repo-defined entries grayed out / skipped
```

Workflow 3 — troubleshooting #3379-style naming conflicts:

```
copilot --disable-repo-mcps # confirm the user-level config works in isolation
copilot # bring repo MCPs back in to reproduce the conflict
```

### Additional context

- Related bug: [#3379](https://github.com/github/copilot-cli/issues/3379) — MCP naming conflict where `/mcp` UI lists user-level entry but runtime uses repo-level settings. The frustration trail referenced above came from trying to work around exactly that bug without a `--disable-repo-mcps`-style flag.
- The existing `--disable-builtin-mcps` flag is a partial precedent for scope-based disabling; this would be its repo-scope counterpart.
- Affected version: 1.0.49-6.