GeezerVison

What this PR does / why we need it

test_install_kserve_with_feast installs kserve into the interpreter running the unit suite, with no isolation and no cleanup, so it mutates the environment every other test is using.

Feast pins psutil==5.9.0 and kserve 0.15.2 requires psutil<6.0.0,>=5.9.6, so pip cannot leave the installed version in place — it uninstalls psutil, then installs 5.9.8:

Attempting uninstall: psutil
  Found existing installation: psutil 5.9.0
  Uninstalling psutil-5.9.0:
    Successfully uninstalled psutil-5.9.0
Installing collected packages: … psutil …

make test-python-unit runs pytest -n 8, so eight workers share one environment. Any test importing psutil during that window fails, including every test that shells out to the CLI, since feast/metrics.py imports it at module scope. That is how an unrelated docs PR picked up a red unit-test-python (3.12, ubuntu-latest) on test_3rd_party_providers with ModuleNotFoundError: No module named 'psutil'. Because it depends on worker timing, a re-run usually passes and it reads as flake.

kserve also pulls protobuf down to 4.25.x, which leaves the environment broken for the next run: the installed grpcio-health-checking ships protobuf 6.x generated code importing google.protobuf.runtime_version. The first run passes, because collection imports precede the mid-run install; the second fails at collection.

--dry-run performs the same resolution and still exits non-zero when the versions cannot be satisfied together, which is what the test guards against, without installing anything.

This also replaces the conflict assertion, which was inverted:

conflict_occured = "dependency conflicts" in err and "ERROR" not in err

That is only true when pip reports conflicts without an error, so a run failing loudly set it to False. The exit_code == 0 assertion was already doing the real work; it now carries pip's output for diagnosis.

Which issue(s) this PR fixes

Closes #6732

Misc

Verified both directions, so the detection is unchanged rather than merely quieter:

• clean resolution exits 0, performs the full resolve (Would install … psutil-5.9.8 …), and leaves psutil at 5.9.0 with kserve not importable afterwards
• pip install --dry-run kserve==0.15.2 psutil==5.9.0 exits 1 with Cannot install kserve==0.15.2 and psutil==5.9.0 because these package versions have conflicting dependencies

The full unit suite now passes twice in a row — 2529 passed, 20 skipped both times, with psutil still 5.9.0 and protobuf still 6.33.6 after the first. Previously the second run produced 31 failures and 8 collection errors. The test also drops from about 13s to under 2s.

This needs a kind/ label, which I cannot add as an outside contributor.