Support multiple remote toolsets via URL for managed MCP clients without custom headers

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

The hosted GitHub MCP server currently supports a single toolset by URL (`/mcp/x/{toolset}`) and multiple toolsets through the `X-MCP-Toolsets` request header.

That leaves managed MCP clients that expose the server endpoint and OAuth configuration but do not allow arbitrary per-request HTTP headers unable to select a bounded combination of toolsets. One concrete example is a ChatGPT custom/developer MCP app: its current app configuration flow exposes endpoint/metadata/authentication and tool scanning, but not an arbitrary `X-MCP-Toolsets` header field.

The practical choices are therefore currently:

1. remain on the default toolset and lose useful optional capabilities;
2. create several separate MCP app connections, one per `/x/{toolset}` URL; or
3. use `/x/all`, which exposes substantially more tools than needed and works against least-privilege/tool-surface minimization.

My concrete desired bundle is:

`default,actions,projects,git,notifications,governance`

The use case is an interactive GitHub MCP connection that needs ordinary repository/issue/PR operations plus CI inspection/control, Projects, repository tree access, notifications, and governance, while intentionally not exposing unrelated toolsets.

### Proposed solution

Add a URL-addressable way to select multiple toolsets on the hosted remote server, while preserving the existing header behavior. For example, one of:

- `/mcp/x/default,actions,projects,git,notifications,governance`
- `/mcp?toolsets=default,actions,projects,git,notifications,governance`
- another documented, URL-safe equivalent.

Requirements I would suggest:

- use the same validation/normalization as `X-MCP-Toolsets`;
- support the `default` pseudo-toolset plus additional toolsets;
- reject unknown toolsets rather than silently broadening access;
- remain composable with `/readonly` and existing URL-addressable modes where applicable;
- keep headers authoritative when both mechanisms are present, or document an unambiguous precedence rule;
- do not make `/x/all` the required workaround for managed clients.

### Example prompts or workflows

A managed ChatGPT MCP app could point to one stable endpoint representing exactly the approved bundle, then scan tools normally. The same pattern would help other hosted/managed MCP clients that cannot inject custom headers.

### Why this matters

GitHub already recommends selecting only the toolsets needed because tool-surface size affects model tool selection and security. URL-addressable multi-toolset selection lets managed clients follow that recommendation instead of choosing between missing capabilities, duplicated app connections, or `all`.

This request is separate from #3231 / PR #3232, which address patch-safe large-file updates.

Start by tracing the hosted remote server's URL routing for /mcp/x/{toolset}, /readonly, and /x/all, then compare it with the existing X-MCP-Toolsets validation and normalization. Define and document one URL-safe multi-toolset form, including precedence when headers are also present. Done means managed clients can select a bounded, validated bundle without using /x/all.

Rédigé par le modèle d'indexation à partir du texte de l'issue.