main is RED on CPU: test_online_gate_client and test_serve_low_tools fail after the server-rename repair landed without updating the tests that pinned the old path

[localai-bot]

main fails two CPU test modules. Reproduced on a pristine checkout of
4b2e7464 with no local changes:

$ python3 -m unittest tests.tools.test_online_gate_client
ValueError: substring not found
Ran 30 tests ... FAILED (errors=1)

$ python3 -m unittest tests.tools.test_serve_low_tools
Ran 1 test ... FAILED (errors=1)

Cause

2b262622 (BENCH-SERVER-BINARY-RENAME, issue #222) replaced the literal guard
in scripts/dgx-online-serving.sh with a resolution + fallback:

297: server_bin="${build_dir}/examples/vllm-server"
298: [[ -x ${server_bin} ]] || server_bin="${build_dir}/examples/server"

but tests/tools/test_online_gate_client.py:1006 still asserts the old literal:

script.index('[[ -x ${build_dir}/examples/server ]]')

str.index raises ValueError when the substring is gone, which is the
substring not found above. :2250 and :2423 still build fixture paths named
examples/server as well.

The repair itself is right and needed — the harness genuinely could not find the
binary (#222). What did not happen is updating the tests that pinned the old
spelling, so the change landed red.

Why this needs an owner now

• It is not covered by SACRED gate red on main: test_glm4_moe_lite_paged_engine diverges in tokens (plus 4 more pre-existing ctest failures) #233 or Four pre-existing CUDA ctest failures on main, attributed but unowned: test_capi (SIGSEGV), test_qwen3_apc_e2e, test_minicpm3_paged_engine, test_llama_paged_engine #248. Those are CUDA sm_121a failures; this
  is CPU, reproduces on any box in seconds, and blocks anyone running
  tests/tools/ as a precondition.
• The online-serving gate aborts on current main: harness looks for examples/server, the build produces examples/vllm-server #222 reads as closed by that commit, so nobody is looking.
• It silently weakens the campaign's evidence path: tests/tools/ is the suite
  that guards the online-serving gate, which is how Qwen3.6 NVFP4 baselines (27B and 35B-A3B) must reach vLLM speed parity #213's throughput numbers are
  supposed to become accepted evidence.

Fix

Re-derive the three sites from the artifact the build actually emits, rather than
reverting the shell change:

• tests/tools/test_online_gate_client.py:1006 — assert against the resolution
  main now performs, including its fallback, not a single literal.
• :2250, :2423 — fixture files should be named vllm-server, since they stand
  in for the artifact the harness reads.
• tests/tools/test_serve_low_tools.py — its own failure is the shellcheck-style
  case over the same script; confirm whether it is the same root cause.

Related work already in flight

PR #229 (row/GATE-SERVER-BINARY) independently fixed this exact class before
2b262622 landed: it re-derived those three fixture/assertion sites AND added
tests/tools/test_online_gate_server_binary.py, a guard that parses OUTPUT_NAME
out of examples/CMakeLists.txt instead of hardcoding a spelling, plus a repo
scan for stale examples/server references.

That PR is mid-rebase over 2b262622/8fce04d3. Note for whoever picks this up:
main's fallback at :298 is a legitimate use of the old string, so the
scan must accept it rather than flag it — the guard has to describe reality, not
force one spelling.

Two sessions fixed the same bug in parallel here; that duplication is how the
test update got dropped. Worth a coordination note as much as a code fix.