docs(inference): correct stale serving_tokens.py docstrings for vLLM 0.22

[hallerite]

The module docstring + inline comments said vLLM 0.20 and claimed data_parallel_rank header routing and server-side max_tokens defaulting are "not in the upstream protocol" / "drop once vLLM patches upstream". The pin is now 0.22.0, and both have landed upstream in ServingTokens (verified against the installed vLLM source).

Reworded so it reflects reality (upstream covers them; we keep equivalent guards; the genuinely prime-RL-specific piece is the compact routed_experts export) and retargeted the stale OpenAIServingChat analog references to upstream ServingTokens.

Comments/docstrings only — no code changes. The usage field is still genuinely dropped by upstream's response schema, and the kv_transfer_params note is left untouched (unverified). Surfaced by the verifiers-v1 redundancy audit; the override code for DP-rank/max_tokens is now arguably redundant too — a possible follow-up.

---

Note

Low Risk
Documentation-only changes with no runtime or behavioral code edits.

Overview
Updates comments and docstrings only in serving_tokens.py so they match the vLLM 0.22 pin and current upstream ServingTokens behavior.

The module header and inline notes no longer claim that data_parallel_rank routing and server-side max_tokens defaulting are missing from upstream or “drop once vLLM patches.” They now state that vLLM 0.22 already implements those paths and that prime-RL keeps equivalent guards; the prime-RL-specific extension called out is still compact routed_experts export (plus existing notes like usage / kv_transfer_params are unchanged).

References that pointed at vLLM 0.20 and OpenAIServingChat for max_tokens analogies are retargeted to 0.22 and upstream ServingTokens.

^{Reviewed by Cursor Bugbot for commit ff60e9b. Bugbot is set up for automated code reviews on this repo. Configure here.}