MCP server registration through llmao

LiteLLM has substantial MCP management already, and it maps onto llmao's
existing shape closely enough to be worth using rather than building.

**What LiteLLM provides:**

| | |
|---|---|
| server record | `server_id`, `url`, `transport` (http/sse/stdio/openapi), `auth_type`, `credentials`, `allowed_tools`, `max_concurrent_requests` |
| access | `mcp_access_groups`, `allow_all_keys`, `available_on_public_internet` |
| cost | `mcp_info.mcp_server_cost_info`: `default_cost_per_query` plus `tool_name_to_cost_per_query` |
| per-user keys | `/v1/mcp/server/{server_id}/user-credential` — BYOK, stored per user |
| toolsets | curated tool collections assignable to keys and teams |
| auth types | none, api_key, bearer, basic, oauth2, token exchange, ID-JAG, AWS SigV4, passthrough |

**Two things make this a good fit rather than merely available:**

**There is already an admin-review workflow.** Non-admins call
`registerMCPServer`, which submits for approval; admins call `createMCPServer`
directly. That is the same gate llmao already applies to `/keys/other/new`
(PMC members and site admins), so the authorisation model carries over without
inventing one.

**`mcp_access_groups` parallels the project→team mapping.** llmao already maps
an ASF project to a LiteLLM team; access groups are the same shape one level
down.

**And MCP tool calls are metered.** `default_cost_per_query` with per-tool
overrides means MCP usage accrues against the same project budgets as model
calls — which is more than can currently be said for the models themselves
(see the budgeting issue above).

**Scope for a first pass:**

- list MCP servers a project can reach, on a page beside `/models`
- submit a server for review (committer), approve (PMC or site admin)
- surface `allowed_tools` so a project can see what a server exposes
- leave BYOK credentials and toolsets alone initially — both are per-user
surfaces and add UI weight without proving the model works
**Worth confirming first:** whether MCP servers respect the same virtual-key
scoping as models, or whether a key that can reach a model can reach every
server its access groups allow. That determines whether MCP access is a
property of the project or of the key, and it is easier to get right before
anything is built on it.

Start by tracing the existing /keys/other/new workflow and the registerMCPServer/createMCPServer paths described in the issue, then compare them with the project-to-team mapping. Confirm whether MCP access follows virtual-key scoping before choosing the project or key boundary. Done means a project-facing page beside /models, server submission and approval, and visible allowed_tools, while leaving BYOK credentials and toolsets out of scope.

Written by the indexing model from the issue text.