[Bug]: Standard server platform/metadata-experts returns 404 "Server definition not found" while sibling standard servers serve on the same token; worked on 2026-09-02

### Summary

The standard hosted server `platform/metadata-experts` returns `404 Server definition not found` to `initialize`, immediately, while other standard servers on the same org and the same access token return 200. It served normally on 2026-09-02 and has failed since at least 2026-09-11, so this is a regression rather than a server that was never provisioned. Setup continues to list it Active.

### Environment

Production org (Enterprise Edition), API v67. Client: direct HTTPS POST and Claude Code, both through a pre-registered External Client App (public client, `mcp_api` scope). The access token is minted by JWT Bearer, and the same token is accepted by the sibling servers in the same test run, so this is not an authentication, scope or audience failure.

### Test / repro

One script, three standard servers, same token-minting path, same request body, run 2026-09-12:

```
POST https://api.salesforce.com/platform/mcp/v1/platform/
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"repro","version":"1.0"}}}
```

```
metadata-experts HTTP 404 (0s) {"error":{"code":404,"message":"Server definition not found for: metadata-experts"}}
sobject-reads HTTP 200 (1s) serverInfo {"name":"sobject-reads","title":"SObject Reads","version":"1.0.0"}
salesforce-api-context HTTP 200 (1s) serverInfo {"name":"salesforce-api-context","version":"1.0.0"}
```

### It previously worked

A probe artefact recorded at 2026-09-02T13:45:05.412Z captures a successful `initialize` against the same URL: `serverInfo {"name":"metadata-experts","version":"1.0.0"}`, capabilities for logging, prompts, resources and tools, and `tools/list` returning one tool, `execute_metadata_action`.

Nothing about the URL or the External Client App changed between then and the failure. The only client-side change was moving from the OAuth authorization-code flow to JWT Bearer on 2026-09-11, and that cannot be the cause, because the mint succeeds and the two sibling servers accept the identical token in the same run.

### Relationship to #43

#43 reports **custom** servers returning the same "Server definition not found" message after a Summer '26 upgrade, explicitly noting that standard servers continue to serve, and with a consistent ~30 second delay. This report may or may not share a root cause, but it is the inverse shape: the failing server here is a **standard** one, other standard servers on the same org serve normally, and the 404 is immediate rather than delayed.

### Why this matters

Setup lists the server as Active with one tool, so an administrator reviewing what the org exposes sees a capability that no client can reach, and Setup gives no signal that the endpoint is not serving. The client-side error points at the URL, which is correct and identical in shape to the seven sibling URLs that work, so the natural first diagnosis is a configuration error on the client side. In our case it also confounded a separate investigation, because a server that can never be called behaves differently from one that can, and we spent time treating that difference as evidence about something else.

### Suggested resolution

Restore the server definition behind `platform/metadata-experts`, or, if the server has been withdrawn, deactivate it in Setup and record the withdrawal in the standard servers reference, so that Setup and the gateway agree on what exists.

Start by reproducing the documented initialize request against platform/metadata-experts and compare it with sobject-reads and salesforce-api-context using the same token. Review the behavior described in issue #43 and the Setup status. Done means restoring the standard server definition, or deactivating it and updating the standard servers reference if it was withdrawn.

Written by the indexing model from the issue text.