Support authenticated (OAuth/token) reads of the MCP registry so enterprises don't have to expose it anonymously

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

When a custom MCP registry is configured for an organization/enterprise (for example **Azure API Center**, a documented Copilot-supported registry type), Copilot CLI reads that registry **without any authentication**. The lookup is an unauthenticated request:

```
GET {registryUrl}/v0.1/servers/{name}/versions/latest
Accept: application/json
```

There is **no `Authorization` header** and no way to make the CLI present credentials when reading the registry. This forces the registry to permit **fully anonymous reads**.

For Azure API Center that means enabling *"allow anonymous access"*, which publicly exposes the organization's entire curated MCP inventory — server names, package coordinates, remote URLs, and metadata — to anyone on the internet.

This is a governance contradiction: the MCP allowlist exists to *tighten* security, but adopting it currently requires making the **source of truth** (the registry) world-readable.

There is also a fail-closed interaction: an auth-gated registry returns `401/403`, which is neither `200` (verified) nor `404` (not found), so **all non-default MCP servers get blocked**. A private registry is effectively unusable today.

### Proposed solution

Allow Copilot CLI to **authenticate the registry read** so the registry can stay private. Any one of these would solve it:

- **OAuth 2.0** (client-credentials or device-code) against the registry's auth server — preferred for API Center behind Microsoft Entra ID.
- A configurable **bearer token / API key** header for the registry endpoint.
- **Reuse of the identity the CLI already holds.** The CLI already sends `Authorization: Bearer ` to GitHub's own policy endpoint and to `…/enterprise/v0.1/allowlists/evaluate`; the same authenticated pattern simply isn't applied to the configured registry read.

**Benefit:** enterprises can adopt MCP allowlisting/governance without making their internal MCP catalog public, and private registries (API Center with Entra auth, internal gateways) become usable instead of failing closed.

### Example prompts or workflows

- An enterprise admin registers a **private Azure API Center** (Entra-gated) as the org MCP registry. `copilot` authenticates to it, fetches the curated server list, and only allowlisted servers run — **without** the catalog being publicly readable.
- A team fronts its registry with an **internal API gateway** that requires a bearer token; the CLI is configured with an OAuth client and reads the registry over an authenticated channel.
- A regulated org needs an **audit trail** of who reads the MCP catalog. Anonymous access makes this impossible today; authenticated reads tie each fetch to an identity.

### Additional context

- VS Code has the equivalent request: **microsoft/vscode#282456** ("authenticated/OAuth registry reads"). The underlying registry-spec support for auth has been addressed upstream; the client side is the remaining gap.

---

### Spec confirmation: OAuth2 reads are explicitly supported

The MCP registry authorization spec defines the registry as an **OAuth 2.1 Resource Server** and defines a dedicated read scope:

> "The registry acts as an OAuth 2.1 Resource Server, identical to how MCP servers work."
> Scopes: **`mcp-registry:read`** (list/read server metadata), `mcp-registry:write` (publish/update/delete).

- Registry authorization spec: https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/registry-authorization.md
- MCP Authorization Specification (referenced by the above): https://modelcontextprotocol.io/specification/draft/basic/authorization

Authenticated reads are **optional** per spec ("No authentication required by default. Subregistries may optionally require authentication") — but they are a first-class, spec-blessed capability. So this request is purely a **client-side gap**: a custom registry (e.g. API Center behind Microsoft Entra ID) is entitled by the spec to require OAuth on reads via `mcp-registry:read`, and Copilot CLI currently cannot satisfy it because it sends no `Authorization` header on the registry lookup.