fix(metrics): bound fairness_id label cardinality and prune GC'd flow series

[LukeAVanDrie]

What type of PR is this?

/kind bug

What this PR does / why we need it:

The fairness_id label on request and flow-control metrics is populated from a client request header (x-llm-d-inference-fairness-id) or an agent-identity attribute, so its cardinality is not operator-bounded. Prometheus vectors never evict label combinations: every distinct fairness ID ever observed permanently allocated histogram series across both the deprecated and llm_d_epp metric families, growing pod RSS and scrape payloads without bound. This is a metrics-cardinality DoS against EPP memory and the metrics pipeline. Implements the cardinality policy proposed in #2106 (my proposal, awaiting maintainer sign-off). Sending the implementation alongside to make the proposal concrete and reviewable; if the discussion lands on a different option, I'll rework this PR to match.

Three changes, following the existing model-label precedent:

• Bound fairness_id through a boundedLabel limiter (cap 1000, overflow to other) in every record function that takes it, exactly as model names are bounded via boundModels.
• Bound model labels in RecordFlowControlRequestQueueDuration, which was missing the boundModels call its sibling functions have (model names come from the request body).
• Prune a flow's flow-control series from both metric families when the registry garbage-collects the flow, so the vectors track live flows. Pruning runs after cleanupFlowResources and outside the registry lock; DeletePartialMatch scans whole vectors and must not run under it.

Accepted limitations (consistent with the model-label tradeoffs; see #2106 for the rationale): cap admission is first-come rather than allow-listed, and cap slots are never recycled. Memory stays bounded either way; per-tenant observability can degrade under a deliberate ID flood.

FullPath benchmark (registry/flow churn, M4 Pro, -benchtime=3s): 14.5KB -> 4.0KB per op, 264 -> 94 allocs per op.

Which issue(s) this PR fixes:

Per #2106; part of #1187.

Release note:

The fairness_id metric label is now capped at 1000 distinct values; additional fairness IDs are reported under the `other` label value. Flow control metric series for a fairness ID are removed when its flow is garbage collected. This bounds EPP memory and metrics-pipeline load, which were previously unbounded because the label derives from a client-controlled header.

[LukeAVanDrie]

cc: @liu-cong