feat(vllm): install ROCm 10.1 wheels from staging with a cp314 runtime (ROCMAI-439)

[juhovainio]

Summary

Enables a ROCm 10.1 vLLM staging install using a cp314 Python runtime (ROCMAI-439).

• cp314 interpreter detection (apps/rocm/src/therock.rs): ROCm 10.x's vLLM/flash-attn/amd-aiter wheels are cp314-only, unlike every earlier SDK version's cp312 wheels. Interpreter selection previously only switched to cp314 when a stable version was explicitly pinned at ROCm >= 10 (SourceLayout::Next). A plain auto-select or a nightly build-date/prerelease pin on the canonical channel can also resolve to a ROCm >= 10 build without going through that routing at all, so canonical_auto_select_needs_next_python now peeks the channel's live package listing to catch those cases too. ensure_uv_venv also now checks an existing venv's wheel-compatibility python tag against what's required, so a stale cp312 venv from before this fix isn't silently reused once cp314 is required.
• vLLM ROCm 10.x discovery fixes (engines/vllm/src/install.rs):
  • The final install of vllm/flash-attn/amd-aiter resolves full dependencies, which pulls in vllm's own plain-PyPI transitive deps (e.g. lm-format-enforcer) that AMD's index doesn't host. uv treats a 403 from any configured index as fatal, and a CLI --extra-index-url can't opt a non-pytorch index into ignore-error-codes tolerance alongside it, so a generated uv.toml (write_vllm_index_uv_config, passed via --config-file) now does that instead.
  • That same full-dependency resolve can pull in an unconstrained torch from PyPI, undoing the exact ROCm-pinned torch installed just before it. The install now runs a forced torch realignment immediately afterward to restore the pinned build.
  • tensorizer is no longer independently pinned: it has no ROCm-specific build, and vllm's own wheel metadata already declares an exact dependency on it.
• docs/vllm.md: documents the install.rs-side fixes above.
• Test coverage:
  • An offline unit test in install.rs guards the config-file 403 fix and the torch realignment sequencing end-to-end against fake uv/python shims.
  • therock-next-09 (tests/e2e-cucumber) is dropped from @nightly to a per-PR lane, since the discovery mechanism and both fixes above run on every install regardless of which discover-table row is newest.
  • therock-next-09 is extended to also serve the model it just installed and send it a chat completion, reusing existing serve/chat steps. The existing vLLM serving canary (serve-vllm-inference) installs via a plain unpinned SDK install and never exercises the ROCm 10.x discovery route, so without this a discovered wheel that installs cleanly but can't actually load or answer a request would pass undetected.

Test plan

• cargo test -p rocm-engine-vllm (install.rs unit tests, including the new config-file/torch-realignment regression test)
• cargo test -p rocm-core --lib (therock.rs cp314-detection and venv-recreation unit tests)
• cargo test --test feature_naming (e2e feature-file naming/sequencing contract)
• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features
• therock-next-09 live GPU lane (runs per-PR on self-hosted runners)

[juhovainio]

I reviewed this against ROCMAI-439 and the repo's documented conventions (crate-layering, module organization, DCO/test requirements). This is delivered as a comment rather than a formal review because I'm the PR author -- self-review restrictions block REQUEST_CHANGES/APPROVE from the same account as the PR, not because these are advisory.

Two of the inline notes are real bugs worth fixing before merge:

1. The new interpreter provisioning now runs before the channel/arch validation it used to run after, so a doomed request (wrong channel, or a --family with no exact arch match) pays for a full uv python install of 3.14 before failing instead of failing fast.
2. The managed-Python cache's identity check doesn't account for the fact that version now depends on layout, so switching between a canonical install and a ROCm 10.x one will thrash the cache on every switch instead of keeping both interpreters around.

The rest are smaller: a naming deviation from the ticket worth a line in the description, one duplicated-parsing-logic smell, a documentation/primitive-obsession note that isn't blocking, and a stale test comment contradicted by this PR's own doc-comment update two hunks over.

One thing I checked and didn't flag: this PR bundles the ROCm 10.1 staging wheels and the cp312-to-cp314 interpreter switch in one commit. They're tightly coupled (10.1's wheels only exist for cp314), so I don't think this needs splitting, but calling it out in case a reviewer expected two smaller commits.

No scope creep, no missing tests I could find, docs/vllm.md and the e2e feature file are both kept in sync with the behavior change.

[jussielo-amd]

Reviewed the vLLM ROCm 10.1 staging-wheel install path in detail, with particular focus on the supply-chain angle given it installs from a "staging" index.

Supply chain: verified independently (not from the PR description) — both the 10.1 frameworks-prereleases.amd.com and existing 10.0 frameworks.amd.com index URLs are legitimate AMD-owned HTTPS infrastructure following AMD's established naming convention, no typosquat/insecure patterns. Every package resolves to an exact pinned version via uv pip install --dry-run before install — never unpinned. New guards (ensure_rocm_local_version_matches, ensure_discover_python_tag) fail closed if the staging index's mixed ROCm 10.0/10.1 wheels or the interpreter's ABI tag don't match the target. No CI/workflow changes, no new egress or secrets.

Quality: cargo test (1458 tests across rocm-engine-vllm/rocm-core/rocm), cargo fmt --check, cargo clippy, and xtask check-crate-edges all clean.

Two minor non-blocking notes for a follow-up, not blocking this PR:

• cp314 is hardcoded independently in therock.rs's python_requirement() and each install.rs discover row — nothing enforces they stay in sync if a future ROCm point release changes the CPython tag.
• Small hard-wrap artifact in docs/vllm.md (cosmetic only).

Approving — solid, well-tested change with good defensive guards for the exact cross-contamination risks a staging multi-version index introduces.