vLLM install failure on an unsupported interpreter or glibc surfaces misleading uv advice

rocm engines install vllm pins the ROCm build of vLLM (vllm==<version>+rocm<abi>), which is published as a single wheel — currently CPython 3.12 on glibc >= 2.34. On any other host the install correctly fails rather than falling back to the generic PyPI build. That behaviour is intended.

The problem is what the user is told. install_vllm_with_uv surfaces uv's raw resolver output, and for an unsatisfiable pin that output leads with dependency-confusion wording and suggests --index-strategy unsafe-best-match. The suggestion does not help here — the wheel genuinely does not exist for that interpreter/glibc — and if followed via UV_INDEX_STRATEGY it reintroduces exactly the unpinned PyPI fallback the pin exists to prevent.

Affected hosts include any 3.13 interpreter, and distributions whose glibc is older than 2.34 such as RHEL 8 (2.28) and SLES 15.7 (2.31), all of which rocm install driver otherwise supports.

Suggested fix: on that failure path, lead with the real cause — no ROCm vLLM wheel is published for this interpreter and glibc combination — and say explicitly that widening the index strategy is not a workaround. Leaving uv's own text below it is fine.

Raised during review of #176 and deliberately left out of scope there, as it is separable from the pin itself.

Start at the install_vllm_with_uv entry point and inspect how uv resolver failures are surfaced. Reproduce or trace the unsupported interpreter/glibc case, then confirm the message leads with the missing ROCm wheel explanation, warns that widening the index strategy is not a workaround, and retains uv's output below it.