fix(tests): the two sanitizer defects actually red on main (#395, #396)

[localai-bot]

Summary

Triage of the sanitizer half of #274, plus the two defects that triage actually
found. Both sanitizer lanes are red on main; neither failure is one of the six
#274 lists.

The six in #274 were #301 (five misaligned BF16 reads from borrowed
safetensors mmap) and #321 (AsyncLLM output thread using a freed
PromRegistry). Both landed in PR #344 (ea4deb20). A full local run of the CI
recipe at main 0eb049f7 confirms all six are green and finds exactly one
failure per lane instead:

Lane	Result at 0eb049f7	Issue
address,undefined	99% tests passed, 1 tests failed out of 384 — test_punica_cpu	#395
thread	99% tests passed, 1 tests failed out of 384 — test_lmcache_client	#396

Closes #395.
Closes #396.

#395 — test_punica_cpu reads past a_stacked

ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 4 at 0x50d0000001a0 ... 0 bytes after 144-byte region
    #0 RefShrink tests/vllm/lora/test_punica_cpu.cpp:63
    #1 DOCTEST_ANON_FUNC_13 tests/vllm/lora/test_punica_cpu.cpp:312

The case add_shrink leaves a -1 slot's buffer row UNTOUCHED, not zeroed feeds
idx = {1, -1, 0, num_slots} deliberately, to prove the kernel skips an
out-of-range slot. Production AddShrink does exactly that
(src/vllm/lora/punica_cpu.cpp:128). The test's own reference helper guarded
only s < 0, so it read a[36..53] out of a 36-element adapter to compute a
value the checking loop then discards. The reference now skips what the kernel
skips.

New since the last green main sanitizer run: 03b615eb (#278) added the case
and is not an ancestor of dbd0d51c, which was green (run 31493332021).

#396 — MockLmcacheServer races its own accept thread

WARNING: ThreadSanitizer: data race
  Write of size 4 by main thread:  ~MockLmcacheServer ...test_lmcache_client.cpp:76
  Previous read of size 4 by T1:   Run ...test_lmcache_client.cpp:206

stop_ was made atomic; listen_fd_ was not. The destructor closes and
reassigns it before joining, so that write races the accept thread's read of
the same plain int. The mock is duplicated in test_lmcache_client.cpp and
test_lmcache_connector.cpp and both carry it — which is why CI reported the
connector on #311 and the local suite reported the client. Both fixed: publish
the descriptor once the socket is ready, hand it over with exchange(-1), read
it through load().

Verification

RED, at 0eb049f7, CI recipe (-DVLLM_CPP_BUILD_TESTS=ON -DVLLM_CPP_CUDA=OFF -DVLLM_CPP_SANITIZE=…, VT_POOL_BYPASS=1, serial ctest):

• ASan/UBSan full suite: 1/384 failed — test_punica_cpu, report byte-identical
  to hosted job 93821547189
• TSan full suite: 1/384 failed — test_lmcache_client, same race hosted job
  93616755110 reported against the connector

GREEN, re-verified after merging origin/main 0b7fbff7:

• ASan/UBSan focused, 3/3
• TSan focused, 5 consecutive runs, 3/3 each (10/10 before the merge)
• -Wall -Wextra clean in both lanes, so the plain lane's -Werror holds
• scripts/agent-preflight.sh and --staged: all gates green

Mutation, to show the punica case still catches its defect: dropping
slot >= num_slots from production AddShrink moves the ASan report from the
test helper to punica_cpu.cpp:129 and the binary aborts. Tree restored
byte-for-byte.

No suppression file, no sanitizer flag change, no expected-to-fail marking.

Notes for #274

• .github/workflows/ deliberately untouched — the CI half of main is not verified by its own CI: every run is cancelled, and 5 tests fail under ASan/UBSan #274 is being
  worked concurrently.
• PromRegistry::SeriesFor returns a reference into a vector it reallocates: sanitizer lanes are RED on main #330 (PromRegistry::SeriesFor returning a reference into a reallocating
  vector) is still OPEN but its fix 2efb5680 is an ancestor of main;
  test_llm_engine is green on both lanes here. It looks closeable.

[localai-bot]

Fresh review at da543d83: PASS, three low non-blocking findings. All three answered in 75cbc7b9, which is records + comments only — no behaviour change to the fix.

Reviewer evidence worth keeping in the PR record (their runs, not mine):

• Mutation A — reverting only the RefShrink guard reproduces the ASan heap-buffer-overflow at that line. The fix is motivated.
• Mutation B — dropping slot >= num_slots from production AddShrink moves the report to punica_cpu.cpp:129 and the test still fails, so the change did not weaken the case. They went further and built a plain -O2 non-sanitized driver on the same inputs: 6 REQUIRE(got == kSentinel) violations, so the assertion catches a dropped kernel guard even where ASan is not running.
• Mutation C — reverting listen_fd_ to a plain int in test_lmcache_client.cpp reproduces the race at 7/25 runs (28%). After the fix: 0/50 on the client and 0/25 on the connector. Note for future CI readers: doctest prints 3 passed / Status: SUCCESS! on a racing run — the only signal is TSan exit 66.
• num_slots = a.size() / a_stride checked at all three RefShrink call sites: exact at each, and fail-safe by construction (integer division floors, so any accepted s satisfies (s+1)*a_stride <= a.size()). The narrower-rank case at :340 does not call RefShrink — it carries its own inline reference.
• Roadmap issue table is main's version plus exactly the new rows, every other key byte-identical.
• Zero warning: lines across both full sanitizer builds.

Findings and what 75cbc7b9 does about them:

1. main is RED on sanitize-cpu (address,undefined): test_punica_cpu RefShrink reads past a_stacked for an out-of-range slot #395/test_lmcache_connector data race under TSan: MockLmcacheServer writes non-atomic listen_fd_ before joining its accept thread #396 were linked from the roadmap table and this PR but not from the row specs, which AGENTS.md requires to agree. Added to specs/lora-adapter.md and specs/lmcache-cpp-client-connector.md, each stating what the bug actually was.
2. Mutating BgmvShrink's s >= num_slots guard away leaves test_punica_cpu green — its fixture never feeds an out-of-range index. Same for BgmvExpandSlice. Pre-existing since 1d37f152, not this PR, and a different fixture change from this scope: filed as test_punica_cpu does not cover the out-of-range slot guard in BgmvShrink or BgmvExpandSlice: dropping either leaves the suite green #400 with the one-line close, and added to the roadmap table.
3. The exchange(-1)-then-close() vs a stale load() question: not reachable here (two threads, the destructor opens nothing and joins before returning, worst case EBADF which is the loop's intended exit). Named as an accepted residual in a comment at both sites, including why deferring the close() past the join is not the fix — on Darwin shutdown() alone does not wake accept().

Re-verified after the edits: ASan/UBSan 2/2, TSan 5 consecutive runs 2/2, zero warnings, agent-preflight.sh --staged all green.

[localai-bot]

Hosted CI green at 75cbc7b9 — both sanitizer lanes pass, which is the first fully green sanitize-cpu pair through this window:

sanitize-cpu (address,undefined)   pass   35m14s   job 93887124466
sanitize-cpu (thread)              pass   23m53s   job 93887124490

Everything else on the run is green too: build-test-cpu (26m30s), build-test-cpu-arm64, build-test-vulkan, verify (cpu), verify (vulkan), agent-record, commit-protocol-tag, documentation-checkpoint, device-leakage, cuda-arch-features, vulkan-spirv-freshness, pr-size, plan. Only cuda-fat-build is still running.

That closes the loop on #274 finding #1: the lane was red on main for four distinct defects across this window (#301, #321, #395, #396), it is green here, and it can now tell a regression from the floor again.

Not merging — merge authority is not recorded in developer preferences and this is a helper claim. Ready for an operator to rerun the gate and land.