[deps] Pin torch to pytorch-cpu index in the vllm extra

[AlienKevin]

The vllm extra installs vllm-tpu, which transitively depends on torch but does not pin which index to use. Without an explicit binding, uv resolves the transitive dep against the default PyPI index and installs the CUDA build wheel. On TPU workers this crashes at module init with libcublas.so.*[0-9] not found in the system path, because torch's _load_global_deps preloads the CUDA runtime libraries that don't exist on the TPU workers.

The bug is normally hidden by uv.lock pinning torch to the cpu index from the cpu/tpu extras. It surfaces on Iris workers because those workers drop uv.lock from the workspace bundle when it exceeds 1MB (Kubernetes ConfigMap limit) and fall back to a fresh uv sync --extra vllm resolve, which then picks the wrong torch wheel. This was first hit by the SWE-ZERO multi-language experiment in #4653 — every preempted worker that had to do a fresh resolve crashed at vLLM startup until the script was rewritten to spawn vllm via subprocess and the user was instructed to pass --extra vllm --extra tpu manually.

Fix: add an explicit torch==2.9.0 (and matching torchvision) pin to the vllm extra and route it to the pytorch-cpu index via [tool.uv.sources]. Also declare a vllm/gpu mutual-exclusion in [tool.uv.conflicts] since marin only ships vllm-tpu (no vllm-cuda variant) and the two extras would otherwise conflict over which torch index to use during full-workspace locking.

Verified by running uv sync --package marin --extra vllm in a clean worktree off main: torch resolves to 2.9.0+cpu, torch.cuda is None, import torch succeeds without libcublas. After this lands, --extra vllm alone is sufficient on Iris TPU workers and the --extra vllm --extra tpu workaround can be dropped.

Fixes the libcublas.so.*[0-9] not found in the system path crash hit by #4653.