feat(playground): list the deployments, not whatever the gateway serves

[imneov]

What type of PR is this?

• feature

What this PR does and why

The Playground listed every model any gateway route answered /v1/models for. On a shared gateway that is the wrong set twice over:

• it shows models the deployment pages do not know about (routes written by hand or by other tools), and
• it shows nothing for a deployment whose route is not ready yet: the route does not answer, so the probe drops it.

The deployment pages and the Playground then disagree, and the one model a user just deployed is the one they cannot find. Models were also keyed by served name, so two deployments serving the same name (two versions of one catalog entry, say) collapsed into one entry that always went to the first route.

This PR makes the Playground list the deployments the deployment pages list, each joined with what the gateway says about its route:

• Backend. The model index keeps each route's own model list and why a route listed none. GET <prefix>/routes returns it. A request carrying X-ModelSphere-Route goes to that route (it must be one of the gateway's routes), so a turn reaches the deployment picked even when another route serves the same name.
• Frontend. The model select lists swiss deployments (targets.ts, joinTargets), ready ones first: a ready one as release · served name and sent to its route; one not ready greyed out with why (no gateway route / route not on the gateway yet / route has no ready instance). Routes no deployment owns are left out. With deployments but none ready, the page lists each with its reason and a link to its page; with none, it says no model is deployed yet and links to Model Serving.

Shortcomings: one page of 100 deployments is listed, the largest page swissd serves. View Code still shows the served name only; the snippet goes through /v1, which routes by name.

Which issue(s) this PR fixes

None; follow-up to #36.

How it was tested

• go test ./... (new TestPlaygroundByRoute: per-route listing including a route that does not answer, the header picking a route over the name, an unknown route refused).
• joinTargets unit tests: ready first, the three not-ready reasons, routes no deployment owns left out.
• On a test cluster: the real deployment list (one deployment without a gateway route, two hand-written routes on the gateway) shows only that deployment, greyed out with its reason. With a deployment list pointing one release at a live route, the release is picked by default, a turn streams back from that engine, and the same body sent with the header naming another route is answered by the other engine. No deployments: the "no model deployed yet" hint, in English and Chinese.

Checks

• go test ./... and gofmt -l . is empty
• npm run typecheck && npm test && npm run build in web/ (if web/ changed)
• helm lint --strict helm/console (if the chart changed) (no chart change)
• Docs updated where behaviour, a config key or a chart value moved (no docs describe the list)
• No internal hostnames, IPs, registries or credentials

Notes for reviewers

Start at web/src/modules/playground/targets.ts (the join) and routeByModel in internal/server/models.go. A target's id is its route, so Chat and Compare keep holding a string id; useTarget turns it into the served name and route at request time.

Release note

The Playground lists the models deployed from Model Serving instead of everything the gateway serves; a deployment that is not ready is shown greyed out with why.

🤖 Generated with Claude Code