feat: Brokered MCP Server with CIMD Authentication

### Question: does #988's stance against brokering a downstream MCP server's own OAuth (CIMD) still stand?

## Context

MCP servers that authenticate the real end user via their own IdP using Client ID Metadata Documents (CIMD) — an increasingly common, spec-endorsed pattern (e.g. `@backstage/plugin-mcp-actions-backend` makes CIMD its primary path) — can currently only be onboarded to the registry in catalog mode. None of the egress modes broker a downstream's own IdP (`oauth_user` needs a pre-registered `client_id`/`secret`; `obo_exchange` needs the backend to accept a gateway-minted JWT), and caller auth headers are stripped before any non-internal upstream (`_forward_headers`, #1266), so a client-supplied backend token can't traverse the gateway either.

We found #988, which deliberately declines gateway-brokered downstream-IdP auth ("we'd be running a federated identity service") and designates catalog mode as the pattern for backends with their own IdP.

## The concern (opinion)

For CIMD-authenticated servers, routing them to catalog mode is — in our view — a reduction of the product from (gateway + registry) down to (registry only): discovery still works, but everything the gateway adds on the data path (a single governed endpoint, centralized identity/entitlement enforcement, audit, egress control) is dropped. As CIMD adoption grows, the gateway half of the project quietly stops applying to a growing class of servers — which feels like it undercuts the reason the project is a gateway and not just a registry.

We also note work that looks adjacent to brokering such downstreams: public PKCE egress clients (#1613, merged), client-side DCR on egress (#1519), and publishing the registry's own CIMD document (#992).

## Questions

1. Does the position in #988 still stand as the intended long-term design?
2. Given #1613 / #1519 / #992 moving the gateway toward acting as a dynamic OAuth client to downstreams, is brokering a CIMD (or DCR) downstream on the data path being reconsidered — or are those strictly scoped to other goals?
3. Is catalog mode considered the permanent answer for CIMD-authenticated servers, with the gateway intentionally staying out of their data path?

No files or tests are named. Start by reading the linked context issues #988, #1613, #1519, and #992, then inspect where `oauth_user`, `obo_exchange`, and `_forward_headers` are handled in the gateway egress/auth path and where catalog mode diverges. Compare those implementations to see what portions of auth and data-path enforcement are skipped. Done is a maintainer decision plus a clearly scoped follow-up for implementation or documentation.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.