[Feat][Router] Add per-algorithm routing decisions counter (Refs #474)

[banlor]

What this changes

The request counter shows request volume, but it cannot explain which routing path selected a backend. This redesign adds a routing-decision counter for primary choices, fallbacks, retries, and prefill/decode selections.

• Routing methods still return URL-compatible strings. Selection metadata is carried by an immutable RoutingDecision string subtype.
• The counter records only algorithm, decision, and reason.
• Load-aware routing validates the current LMCache instance identity before crediting a cached prefix, including same-URL restarts and unavailable holders.
• Multipart dispatch awaits async routing methods instead of calling them synchronously.

Cardinality

All three labels use explicit allowlists: 9 algorithms × 6 decisions × 10 reasons, for at most 540 label combinations per registry. Backend IDs, URLs, model names, and request metadata are not labels.

Tests

• 58 focused routing-decision, KV-aware, and load-aware tests pass.
• The full router suite reports 256 passed with the same 3 Windows-only parser expectation failures as clean main.
• Pre-commit passes on every changed file.

Closes #474

[gemini-code-assist]

Code Review

This pull request introduces a new Prometheus metric, routing_decisions_total, to track routing decisions across all router implementations. It adds logic to record these decisions with labels for server, model, algorithm, and outcome. Feedback suggests that the KvawareRouter should specifically record a fallback outcome upon a KV cache miss when a session ID is present, and that the test suite should be updated accordingly.

[ruizhang0101]

I am wondering what is the use case for this metrics? IIUC, each request will go through routing decision. So if we don't consider retry or fail, they should be the same?

[banlor]

Hi @ruizhang0101, good to see you again. Sorry I left this hanging for so long.

You’re right. In the simple case this mostly duplicates the request counter. The useful part is seeing where traffic goes and when routing falls back or retries. I checked current main and this PR is too stale to revive as is, so I’d rather rework it around those cases. What do you think?

[banlor]

Reworked this around the gap you pointed out. The counter now records bounded algorithm, decision, and reason labels for fallbacks, retries, and prefill/decode selections, which the request counter does not expose. Backend IDs and URLs are excluded so cardinality stays bounded.

[banlor]

@ruizhang0101 any feedback on the revised routing counter? It now covers routing choices and fallbacks rather than request volume.

[banlor]

#1079 is waiting for review too. @Shaoting-Feng could you take a look at the routing counter changes here?

[banlor]

The routing counter changes here and the resource requests and limits in #1079 are still awaiting review. @YuhanLiu11 could you look at them?