fix(comfyui): pin managed torch stack during install (EAI-8051)

[fredespi]

Summary

rocm comfyui install installs ComfyUI's dependencies into the machine's managed ROCm runtime. It already filters torch/torchvision/torchaudio out of ComfyUI's direct requirement specs, but nothing scopes package resolution — so a transitive ComfyUI dependency can still resolve torch from PyPI, pull a CUDA build plus nvidia-* wheels, and displace the runtime's ROCm torch. The runtime the whole machine serves models with then becomes a CUDA build with no AMD GPU support: installing an optional app breaks the base runtime (and vLLM serving with it).

This pins the managed runtime's existing torch stack to its exact installed versions so the resolver can never swap in a CUDA build.

Changes

• Before running uv pip install for ComfyUI's deps, probe the managed runtime's currently-installed torch/torchvision/torchaudio versions via importlib.metadata (no native import needed).
• Write those as a uv --constraint file and pass it to the install. The resolver treats the stack as already satisfied and never replaces it; because ROCm torch has no nvidia-* dependencies, none are pulled in.
• A genuine version conflict (a dep needing an incompatible torch) now fails the install loudly instead of silently corrupting the runtime.
• Added unit tests for the constraint-line generation and the --constraint argument wiring.

Test plan

• cargo test -p rocm (Linux) — 477 tests pass, including 3 new ComfyUI tests.
• cargo clippy / cargo fmt --check clean.
• End-to-end proof is the @requires-gpu @nightly scenario comfyui-install-preserves-the-rocm-runtime from test(e2e): pin the ComfyUI runtime-preservation contract (EAI-8071) #291 (EAI-8071), which runs on a GPU host after that contract lands.

[r0x0r]

Reviewed — the approach is sound. Pinning the runtime's torch stack to its exact installed versions (local +git… identifiers and all) via a uv --constraint file is the right lever: a transitive dep that wants a compatible torch is satisfied by what's already there (no reinstall), and a genuinely incompatible one fails loudly instead of silently swapping in a CUDA build. I checked the TORCH_STACK_VERSION_PROBE string — the Rust \-line-continuations strip the source indentation and the \x20 escapes re-supply it, so the emitted Python has valid, consistent block indentation. The pure helpers are unit-tested, and the end-to-end CUDA-rejection proof is the @requires-gpu @nightly comfyui-install-preserves-the-rocm-runtime scenario in #291 — a gated lane, named per AGENTS §3.

One substantive thread on the scope of the guarantee below.

[r0x0r]

Approving. The transitive-torch defect (EAI-8051) is fixed at the right layer: the managed runtime's exact torch/torchvision/torchaudio versions are pinned via a uv --constraint file, so the resolver treats the ROCm stack as satisfied and can never swap in a CUDA build, while a genuine conflict fails loudly instead of silently corrupting the runtime. The \x20-escaped Python probe reconstructs to valid indentation, and the pure helpers are unit-tested. My one thread -- whether "constrain only what's installed" leaves a partial-stack gap -- is resolved: the follow-up commits document (and I verified) that therock installs the full trio atomically as a mutually-compatible set (select_matching_pip_package_versions bails otherwise) and ComfyUI's select_runtime only ever targets a managed wheel runtime, so the partial-stack case cannot arise. End-to-end CUDA-rejection proof is the @requires-gpu @nightly scenario in #291, named per AGENTS. 24/24 CI green.