[Bugfix][Dashboard] Dedup healthy_pods_total across router replicas

[banlor]

The "Available vLLM instances" stat panel reads:

count by(endpoint) (vllm:healthy_pods_total)

The metric is emitted by each router replica from its own service-discovery view, so Prometheus stores N time-series per backend (one per scrape target). count by(endpoint) then multiplies the result by router replica count.

Fix:

sum(max by (server) (vllm:healthy_pods_total))

max by (server) dedups across router replicas before summing. The metric is 0/1, so max is effectively OR across replicas. If any router sees a backend healthy, it counts.

Went with max (optimistic) over min (pessimistic) on purpose. During scale-up or SD propagation lag, routers can briefly disagree about a backend's health. For an availability stat, the useful answer is "is there a router willing to route there", and min would under-report during transient lag.

Verification

promtool tests with synthetic series:

$ promtool test rules healthy_pods_test.yml
  SUCCESS

1. 3 routers × 2 healthy backends → old query: 6, new query: 2
2. 1 router × 2 healthy backends → new query: 2
3. 3 routers × 1 healthy + 1 unhealthy → new query: 1
4. Router disagreement (1 healthy view, 2 unhealthy) → new query: 1
5. All unhealthy → new query: 0

Fixes #644

---

• Make sure the code changes pass the pre-commit checks.
• Sign-off your commit
• PR title classified [Bugfix]

[gemini-code-assist]

Code Review

This pull request updates the Prometheus expressions in several vLLM dashboard configurations to use a sum(max by (server) ...) aggregation for counting healthy pods. The reviewer recommends further refining this logic by including namespace and model labels in the max by clause to ensure accurate deduplication and prevent collisions in multi-tenant or multi-model environments.