What this PR does / why we need it:

Every k3 build on dev since 10fd636 (2026-04-16 09:55 UTC, merge of #3055) has failed at the LMCache editable install with:

/opt/venv/lib/python3.12/site-packages/torch/include/ATen/cuda/CUDAContextLight.h:10:10:
fatal error: cusparse.h: No such file or directory

Root cause is a two-hop CUDA-version mismatch that the alignment path added in #3055 can't paper over:

1. The k3 base image was bumped to nvidia/cuda:13.0.2-devel-ubuntu24.04 in [Chore][CI] Upgrade CI base image to CUDA 13.0 #2981 (system nvcc = 13).
2. setup-env.sh installs vLLM from the generic nightly index (wheels.vllm.ai/nightly/vllm/). That index serves both cu128 and cu130 torch wheels on different days — today it's publishing cu128.
3. When torch.version.cuda="12.8" meets system nvcc 13, torch.utils.cpp_extension._check_cuda_version aborts with The detected CUDA version (13.0) mismatches the version that was used to compile PyTorch (12.8).
4. The [Hotfix][CI] Unblock CI: pandas auto-heal + CUDA 12 build toolchain #3055 fallback apt-installs cuda-compiler-12-8 and sets CUDA_HOME=/usr/local/cuda-12.8. But cuda-compiler-*-* only ships nvcc — it does not ship libcusparse-dev, libcublas-dev, etc., which torch/include/ATen/cuda/CUDAContextLight.h pulls in via #include <cusparse.h>. So the build still fails, just later.

Extending the apt install list is a band-aid; the real fix is to stop resolving torch non-deterministically. This PR pins the install to vLLM's per-CUDA-major cu130 sub-index per the official vllm.ai install instructions:

uv pip install -U "vllm[...]" --pre \
    --extra-index-url https://wheels.vllm.ai/nightly/cu130 \
    --extra-index-url https://download.pytorch.org/whl/cu130 \
    --index-strategy unsafe-best-match

torch.version.cuda is now deterministically "13.0" and matches the base image's system nvcc 13. _check_cuda_version passes with the system toolchain — no CUDA_HOME override, no runtime apt install, no HTML scraping.

What gets removed:

• HTML-scraping of wheels.vllm.ai/nightly/vllm/ to locate a wheel URL (no longer needed now that --extra-index-url + --index-strategy unsafe-best-match resolves properly).
• The entire :wrench: Aligning nvcc with torch's reported CUDA version block from [Hotfix][CI] Unblock CI: pandas auto-heal + CUDA 12 build toolchain #3055 (~40 lines: torch.version.cuda detection, nvcc --version parsing, apt cuda-compiler-*-* install, CUDA_HOME switcheroo).

What gets kept:

• Pandas auto-heal loop from [Hotfix][CI] Unblock CI: pandas auto-heal + CUDA 12 build toolchain #3055 — independent of the CUDA mismatch, still needed because vLLM nightlies periodically add undeclared import pandas.
• wait_for_server log-dump improvement from [Hotfix][CI] Unblock CI: pandas auto-heal + CUDA 12 build toolchain #3055 (untouched by this PR).
• [runai,tensorizer,flashinfer] extras.

What gets added:

• A small Python sanity check that compares torch.version.cuda against nvcc --version and fails fast with a clear message if the cu130 pin ever drifts. The previous failure surfaced deep inside ninja as cusparse.h: No such file or directory, which took a while to track back to the real cause.

Special notes for your reviewers:

• If vLLM's cu130 nightly index is briefly empty on some day (e.g. their nightly CI hiccuped), the install will fail loudly here rather than silently drifting into a broken state elsewhere — which I think is the better failure mode.
• If/when we need to support a non-Blackwell, pre-CUDA-13 target again, the pin can be parameterized by an env var (e.g. CI_CUDA_TAG=${CI_CUDA_TAG:-cu130}). Not doing that now to keep the PR focused.
• Tested the install command structure locally by dry-running uv pip install --dry-run against the cu130 indexes; the resolver picks vllm-*.dev*+cu130 and torch-*+cu130 as expected.

If applicable:

• this PR contains user facing changes - docs added
• this PR contains unit tests

Refs #3055, #2981.