fix(install): never let apt remove ROCm packages during dependency setup (EAI-7957)

[fredespi]

Summary

rocm install sdk could remove a working ROCm installation without asking.

Installing vLLM needs the OpenMPI runtime, which the CLI installs through the host package manager with apt-get install -y. That -y assumes yes for package removals as well as installs, so when apt decided to satisfy OpenMPI by evicting the ROCm stack, it went ahead unattended — the SDK install runs this path automatically whenever it has root or passwordless sudo. The field report saw rocm, rocm-hip, rocm-hip-runtime-dev, mivisionx-dev and rpp-dev removed while an older toolchain was pulled in, breaking a working ROCm 7.14 install.

This makes that transaction fail loudly instead of silently destroying the installation.

Changes

• Before running an apt-get install step, simulate it first with apt-get -s and parse the removals apt reports.
• If the transaction would remove any ROCm/AMDGPU package, refuse: print every affected package and tell the user to resolve the conflict manually. This applies on the --yes path and the unattended path alike, since the reported breakage happened unattended.
• Packages are matched by component family rather than an exhaustive list, because ROCm ships hundreds of packages and adds more each release. Many core names are dashless (hsakmt-roct, llvm-amdgpu, rocminfo, hipblas), so matching only on a <family>- shape would miss them.
• The matcher deliberately favours recall: a false positive only asks the user to install by hand, while a false negative breaks their ROCm install. It still leaves the packages these plans legitimately install or swap (openmpi-bin, mpich, libnuma1, libatomic1) removable, so the guard cannot block the very install it protects.
• Other package managers are untouched — dnf/zypper/pacman plans are additive and have no assume-yes removal path.
• The guard fails open if the simulation itself cannot run, so it never blocks an otherwise healthy install.

Test plan

• Unit tests in crates/rocm-core/src/openmpi.rs cover removal parsing (including apt's trailing *), the simulate argv (adds -s, drops -y, tolerates a sudo prefix, ignores non-apt commands), and the package classifier — with the dashless core package names as explicit regression cases.
• New scenario @id:deps-guard-refuses-rocm-removal (tests/e2e-cucumber/features/dependency_guard.feature) covers the user-visible behaviour: it asserts the CLI refuses, refuses before installing anything, and names every ROCm package at risk. It plants a runtime registry entry and stands in for the package manager, so it needs no GPU, no engine install and no network, and runs on the default mock lane.
• Verified as a real regression test: with the guard removed the scenario fails, and passes with it restored.
• Linux container run: clippy clean, 434 unit tests pass, and the e2e suite runs the new scenario green.

The scenario is Linux-only (@requires-os:linux) and assumes an apt host, which every Linux CI lane is; the guard is apt-specific by design. That precondition is recorded in the feature file.

Fixes EAI-7957.