Bug Report: VTAdmin leaks equal dynamic-cluster candidates

Overview of the Issue

When dynamic clusters are enabled, VTAdmin constructs a new *cluster.Cluster from every request's cluster cookie or metadata before comparing it with the cached cluster

When the definitions are equal, WithCluster(...) keeps the existing cluster, but the newly constructed candidate is never stored or closed. Each rejected cluster leaves a schema-cache worker running and retains its client proxies and RPC pools. Open proxy connections are a possible secondary impact, but were not measured

This affects deployments using --enable-dynamic-clusters. In a focused HTTP reproduction, 5 x identical requests created 5 x schema-cache workers; closing the API stopped 1 x worker and left 4 x rejected candidates running

Reproduction Steps

1. Start VTAdmin with --enable-dynamic-clusters
2. Send an HTTP request containing a valid dynamic-cluster cookie
3. Repeat the request several times with the same cookie
4. Observe that each request creates another schema-cache worker even though only 1 x cluster remains cached
5. Close the API and observe that only the stored cluster's worker is stopped

Binary Version

Vitess main at 7563910899de3952b74ecc2bbdc93838690d437c

Operating System and Environment details

macOS 26.5.2
Darwin 25.5.0
arm64