fix(complete): add cu130 extra-index-url to extras pip install

[ductiletoaster]

Summary

Prevents pip from replacing the base image's cu130-built torchaudio wheel with a stock cu128 wheel from PyPI when transitive deps in extra-requirements.txt trigger re-resolution.

Symptom this fixes

After #45 added transformers / peft / sentencepiece / sam2 and friends, a production K8s pod failed to start with:

```
RuntimeError: Detected that PyTorch and TorchAudio were compiled with different CUDA versions.
PyTorch has CUDA version 13.0 whereas TorchAudio has CUDA version 12.8.
Please install the TorchAudio version that matches your PyTorch version.
```

Pod went into CrashLoopBackOff; downstream harmony repo had to revert the image SHA bump (ductiletoaster/harmony#384) to recover service.

Root cause

The complete stage's pip install -r extra-requirements.txt had no --extra-index-url. The base image's PyTorch is built against CUDA 13.0 (torch==2.12.0+cu130) — pulled from https://download.pytorch.org/whl/cu130 by ComfyUI's own requirements.txt during the core build. cu130 wheels are not published on PyPI; PyPI's torchaudio is cu128-only.

When a dep added in #45 (transformers, sam2, or one of their transitive trees) requested torchaudio with a version specifier, pip didn't see the cu130 wheel because the cu130 index wasn't configured for this layer. So it pulled the cu128 wheel from PyPI and replaced the cu130 install — leaving torch and torchaudio compiled against different CUDA versions.

Fix

```diff
-RUN --mount=type=cache,...,target=/app/.cache/pip
+RUN --mount=type=cache,...,target=/app/.cache/pip
source $VENV_PATH/bin/activate && \

• pip install -r extra-requirements.txt

• pip install \

•  --extra-index-url https://download.pytorch.org/whl/cu130 \
  

•  -r extra-requirements.txt
  

```

Pip now sees cu130 wheels for torch-family packages during extras resolution and keeps the matching CUDA version installed.

Note on the cu128 index in core

The core Dockerfile uses --extra-index-url https://download.pytorch.org/whl/cu128 (line 27 of dockerfile.comfy.core), but the resulting image runs torch==2.12.0+cu130. The cu130 install comes from ComfyUI's own requirements.txt pinning specific wheel URLs that win the resolution. Aligning both stages explicitly to cu130 would be a worthwhile cleanup but is out of scope for this fix.

Test plan

• CI rebuilds complete-cuda cleanly (cu130 index reachable from build runners)
• After image is republished, in-cluster comfyui pod boots successfully (no RuntimeError: ... PyTorch and TorchAudio were compiled with different CUDA versions)
• python -c "import torchaudio; print(torchaudio.__version__)" in the new pod shows a +cu130 build
• Bake-in deps from fix(complete): pre-install Impact/Subpack/Inspire deps to avoid load race #44/feat(complete): bake remaining Manager-installed deps + SAM2 pin #45 still take effect (Impact / Inspire / Subpack load without ModuleNotFoundError)

🤖 Generated with Claude Code

[ductiletoaster]

Closing — diagnosis was wrong direction.

Local rebuild of main (with no PRs in flight) reproduced the same crash and traced it back to core, not complete. The core layer uses --extra-index-url cu128, but that flag is additive — pip picks the highest version across PyPI + cu128 index. PyPI now ships torch==2.12.0 (compiled for cu130) which outranks torch==2.11.0+cu128, so the build ends up with cu130 torch + cu128 torchaudio.

The fix belongs in core with --index-url cu128 (replacing PyPI, not extending it) for just the torch family install. A follow-up PR with that approach (and an ARG TORCH_INDEX so cuda/cpu/future variants are parameterised cleanly) is incoming.