ci: keep pins.json in sync with pyproject.toml; cap torch <2.12

[lstein]

Summary

The launcher installs InvokeAI's dependencies from two sources that nothing keeps in sync: pins.json (fetched at the release tag, used for the torch index URL in legacy installs) and pyproject.toml/uv.lock. pins.json drifted — its Linux ROCm index stayed at rocm6.3 after pyproject.toml moved to rocm7.1 — so launcher installs on AMD got ROCm 6.3 wheels, which cannot work at all on RDNA4 cards (#9328). #9337 fixes the immediate URL; this PR adds the guardrail so it can't silently drift again, and caps torch below the version that breaks ROCm installs.

Changes

• New scripts/check_pins.py: fails if any torchIndexUrl entry in pins.json differs from the matching torch-<backend> [[tool.uv.index]] URL in pyproject.toml.
• uv-lock-checks workflow: runs the new check, triggered by changes to pyproject.toml, uv.lock, pins.json, or the check script. Also bumps the workflow's uv from 0.6.10 to 0.11.28 — uv.lock is already lock-format revision 3, which uv 0.6.x cannot parse, so the old pin was stale.
• pins.json: ROCm index bumped rocm6.3 → rocm7.1. This is the same one-line change as fix: bump launcher ROCm torch index from rocm6.3 to rocm7.1 #9337 (needed here for the new check to pass); happy to rebase if that merges first.
• pyproject.toml + uv.lock: base torch constraint capped at <2.12 on linux/windows. torch 2.12.x+rocm7.1 breaks generation ([bug]: Release 6.13.5rc1 not installing ROCm 7.1 as expected #9328; 2.11 works, and the rocm extra pins 2.10.0). The cap only affects legacy (pre-6.14) launcher installs, which resolve this range live against the pytorch indexes instead of using uv.lock — no locked versions changed (uv lock --locked passes; the lock diff is just the recorded specifier). Remove the cap once the 2.12 ROCm incompatibility is diagnosed.

Caveat

Because the launcher fetches pins.json at the release tag, none of this retroactively fixes already-tagged releases (e.g. v6.13.5.rc1 carries rocm6.3 forever). It takes effect from the next tag onward.

QA

• python3 scripts/check_pins.py passes on the fixed files; a negative test (rocm URL reverted) exits 1 with a message pointing at the exact mismatched entry.
• uv lock --locked passes after the constraint change; no package versions moved in the lock.
• Workflow YAML validated.

Related: #9328, #9337, invoke-ai/launcher#131

🤖 Generated with Claude Code

[JPPhoto]

• invokeai/scripts/check_pins.py:32-43: The consistency check only validates entries that already exist in pins.json; it does not require every launcher-supported platform/backend entry to be present. Removing torchIndexUrl.linux.rocm still prints pins.json is consistent with pyproject.toml and exits 0. The launcher's schema (main over in the launcher repo) permits backend keys to be absent, and its legacy install path only adds --index when the selected entry exists. An omitted ROCm entry therefore silently falls back from the ROCm wheel index, causing AMD installations to resolve an unsuitable build or fail. This recreates the exact installation failure the new guardrail is intended to prevent. To expose this issue, add a test that removes each required CPU, CUDA, or ROCm entry in turn and asserts that the checker exits nonzero; the implementation should validate an explicit required platform/backend matrix, not merely iterate existing entries.