Confirm vMCP cuts over to the diagnostics port before #6384 flips the default

Summary

telemetry.Config.ServeMetricsOnTransportPort() — the migration switch introduced in
#6370/#6371 — is consulted in exactly one place: pkg/runner/diagnostics.go, used by
the CLI/MCPServer runner. vMCP has its own path, NormalizeMCPTelemetryConfig in
cmd/thv-operator/pkg/spectoconfig/telemetry.go, which routes TelemetryConfigRef
through to telemetry.Config and therefore sets MetricsOnTransportPort — but
nothing on the vMCP side reads it to decide whether /metrics stays on the transport
port.

Concretely: #6368 (vMCP diagnostics split) already wires vMCP into the switch —
pkg/vmcp/server/diagnostics.go's transportPortMetricsHandler calls
ServeMetricsOnTransportPort() the same way the runner does. But #6368 and #6371 are
separate, currently-unmerged branches off main, so until both land, vMCP's copy of
this logic doesn't exist on main and the CRD-side MetricsOnTransportPort field
that #6371 exposes is settable-but-inert for VirtualMCPServer.

Risk

Once #6384 flips DefaultMetricsOnTransportPort to false, if #6368 has not merged
by then, MCPServer workloads cut over correctly but VirtualMCPServer workloads keep
serving /metrics unconditionally on the MCP port with no way to turn it off — the
opposite of a controlled cutover.

Action

• Confirm #6368 merges before (or in the same release as) the #6384 cutover
• After both land, verify MetricsOnTransportPort set via TelemetryConfigRef /
  spec.config.telemetry actually reaches vMCP's transportPortMetricsHandler
  end to end (an operator-level test, not just the unit tests each PR already has)

Raised by @jhrozek on #6371:
https://github.com/stacklok/toolhive/pull/6371#pullrequestreview-5027693972

Part of #6271. Related: #6384.

Start with pkg/vmcp/server/diagnostics.go and compare its transportPortMetricsHandler with pkg/runner/diagnostics.go, then trace NormalizeMCPTelemetryConfig in cmd/thv-operator/pkg/spectoconfig/telemetry.go. Verify that TelemetryConfigRef and spec.config.telemetry reach the vMCP handler after #6368 and #6371 land, and add or run an operator-level end-to-end test covering the cutover before #6384 changes the default.