[jussielo-amd]

Fixes #650

Problem

render_update_json_installs_the_suppression_guard_around_resolution steers render_update_json's Python-interpreter resolution onto its PATH-unusable branch by overwriting the process-wide PATH env var, under PROCESS_ENV_TEST_LOCK. cargo test runs every test as a thread in one process, so any sibling test thread that spawns a bare-name, PATH-resolved binary (tar, sleep, powershell) during that window can fail with "No such file or directory" / "program not found". Two commits this week alone (bbd80bf5, and the one squashed into 92d82dcd) each retrofitted one more previously-missed tar/PATH-spawning test onto PROCESS_ENV_TEST_LOCK after the race reproduced again, including once during unrelated verification work. That pattern only serializes around the mutation — it never removes it, so a new test that spawns a PATH-resolved binary can reintroduce the race at any time.

Cause

#253 fixed this same problem for two other python-resolver tests by passing the resolver's environment in as a value (PythonResolverEnv) instead of reading the process PATH at the use site. Those tests call the low-level resolver directly, so they could just construct one. This test exercises the higher-level render_update_json instead, and the call chain between them (render_update_json → runtime_update_plan → resolve_latest_for_manifest → resolve_python_launcher) has production call sites of its own, so threading an env parameter through it would touch signatures used well beyond this one test.

Change

Add a #[cfg(test)] thread-local override for resolve_python_launcher's PythonResolverEnv, mirroring the SuppressProgressOutput/PROGRESS_LINE_SINK seam already in this file: a test can point resolution at a fixture directory without ever touching the real PATH, and because it's thread-local, nothing about it can race a sibling test thread. Production builds always see None and fall straight through to the real process environment, unchanged. The target test's PATH/ROCM_CLI_PYTHON mutation and its unsafe blocks for them are gone entirely; it still takes PROCESS_ENV_TEST_LOCK for the one remaining real mutation (ROCM_CLI_DISABLE_MANAGED_PYTHON_BOOTSTRAP, which nothing else in the file reads concurrently).

Two tests back the new seam: one asserts resolving through the override never mutates process-wide PATH (the property this issue is about), and one proves the override's nesting/restore semantics, mirroring suppress_progress_output_contract's equivalent test for SuppressProgressOutput.

Verification

• cargo test -p rocm --bin rocm run 15 consecutive times — all green (1346/1347 passed, 0 failed each run), confirming the race no longer reproduces.
• cargo test --workspace --no-fail-fast and cargo clippy --workspace --all-targets -- -D warnings both clean.
• An independent fresh-context review (4 parallel passes: correctness/logic, AGENTS.md adherence, history, code-comment compliance) found no blocking issues; its two non-blocking findings (the Clone derive not #[cfg(test)]-gated, and comments not explaining the remaining lock/override split) are addressed in the second commit.

Scope and scenarios

Test-only change with no user-observable behavior, so there is no Gherkin scenario to add (AGENTS.md: purely internal changes need none).