tools/bench/serve_low_common.py:135 names a pin sha the record advanced past

[localai-org-maint-bot]

Row: -

This issue has no owning row yet and needs one. It is listed under ## Owed in
.agents/specs/oracle-pin-source-build.md so that it is not orphaned.

The defect

tools/bench/serve_low_common.py:135, inside the docstring of
assert_oracle_commit, states a present-tense fact the tree contradicts:

    and today that constant already CONTAINS `+g555967922` -- so any string that
    passes the equality also passes this function, and it cannot fire in
    production.

VLLM_ORACLE_VERSION reads vllm_runtime_version from
.agents/upstream-sync.md, which is 0.28.1rc1.dev132+ge126687a9. It has not
named 555967922 since e8467758e (2026-09-03) advanced the parity pin to
e126687a9a.

Why it is filed rather than fixed

It was found during the fresh review of #2941
(row/ORACLE-PIN-SOURCE-BUILD), which corrected the comments falsified by the
5d97007c2 source-build sync (#2896). This one was falsified by an earlier
pin advance, not by that sync, so it is outside that row's declared scope
and the row did not touch it. It sits about twenty lines from an edited hunk in
the same file.

What the fix has to decide

The paragraph's argument is that the exact VLLM_ORACLE_VERSION equality runs
first at all three call sites, so assert_oracle_commit cannot fire in
production and is defence in depth. That argument still holds at the current
pin; only the quoted sha is stale. A fix should re-state the sha from the
record rather than transcribe a second copy of it, because transcribing is what
went stale here. The surrounding claim that the assertion earns its place when
a manifest is read from another venv or a future pin records a plain release
number is unaffected and should stay.

No gate moves. This is comment text.