fix: remove mid-stream TPOT predictions from predicted-latency producer

[MicheleCampi]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Removes the mid-stream TPOT prediction path from the predicted-latency producer, as proposed in #2016. The sampled mid-stream prediction in processTokenForLatencyPrediction was observability-only (consumed by recordRequestPredictedTPOT, never used for routing/scoring/admission) and low quality: computed from lastSeenMetrics (the scheduling-time snapshot, not fresh state), averaged together with the scheduling-time TPOT prediction (mixing two incommensurate quantities), and the only remaining caller of buildPredictionRequest that used the scraped vLLM RunningRequestsSize gauge while training entries use the router's in-flight tracker (train/serve inconsistency, see #1856 review).

With the removal, avgPredictedTPOT reduces to the scheduling-time prediction, which is the meaningful predicted-vs-actual comparison, and the gauge/tracker inconsistency disappears by construction.

Scope notes:

• decodeTokenSampler becomes dead code (its only remaining consumer was the removed path, since the actual avgTPOT is computed from e2e latency at end-of-stream) and is deleted along with the write-only tpotObservations field.
• samplingMean and maxDecodeTokenSamplesForPrediction are kept in Config so existing configs keep parsing under the strict decoder, but the values are ignored; a deprecation message is logged when they are set. Their validation is removed accordingly, and the factory test covers the new accept-and-ignore behavior.
• buildPredictionRequest itself and its remaining training-path caller are untouched to avoid conflicts with feat: consume InFlightLoadProducer in predicted-latency producer #1856.

Which issue(s) this PR fixes:
Fixes #2016

Release note:

Removed low-quality mid-stream TPOT predictions from the predicted-latency producer; avgPredictedTPOT now reflects the scheduling-time prediction only. The samplingMean and maxDecodeTokenSamplesForPrediction config parameters are deprecated and ignored.

[github-actions]

🚨 Unsigned commits detected! Please sign your commits.

For instructions on how to set up GPG/SSH signing and verify your commits, please see GitHub Documentation.

[ahg-g]

/assign @kaushikmitr

[kaushikmitr]

dont think this comment is correct. What we are recording is infact TPOT and not ITL

[MicheleCampi]

Good catch — the quantity recorded here is exactly what the codebase calls TPOT (the debug log two lines below labels it actual_tpot_ms, and it feeds the actual side of the predicted-vs-actual comparison). Reworded the comment to say TPOT. Fixed in the rebased commit.

[kaushikmitr]

please rebase.

[MicheleCampi]

Rebased on current main (efb4db5) — clean, no conflicts. The comment wording flagged above is fixed in the same commit; package tests pass on the rebased branch.

[kaushikmitr]

/lgtm

[MicheleCampi]

The e2e-tests failure is unrelated to this PR: the coordinator pod exits cleanly mid-test (pod dump shows llm-d-coordinator 0/1 Succeeded at 1m19s; its logs end with a graceful shutdown after ~70s of healthy readyz), and the request then times out against a backend-less service. The EPP config in that e2e doesn't instantiate the predicted-latency producer at all, and the same workflow fails intermittently on main, including on the docs-only commit this branch is rebased on (efb4db58). Could someone with access re-run it?

[kaushikmitr]

There are commit sign failures

[MicheleCampi]

Done — the commit is now SSH-signed and shows as Verified (3d176dc). Content is byte-identical to the previously reviewed commit; I only re-signed it and dropped a leftover # Conflicts: block from the commit message.