CI: hermetic env for production suites' tool spawns (#823)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Refs #823 (slice 22: package-manager children in the production suites)

Problem

e2e_hosted_production.rs and e2e_vendored_production.rs spawn
their package managers (tool(), corepack(), bundle(), and the
has_command / has_corepack_pm probes) with private scrubs that had
drifted from tests/common/hermetic.rs:

helper	drift
all of them	no SOCKET_* scrub, so an ambient SOCKET_* reached every package-manager child (and any socket-patch it might run)
hosted tool()	removed VIRTUAL_ENV after applying the leg's env, so the uv legs' own VIRTUAL_ENV pin never reached uv
vendored corepack()	removed YARN_NODE_LINKER but not npm_config_node_linker, unlike tool()
probes	ran with no scrub at all, so they didn't answer for the environment the legs run in

Change (test-only, 2 files)

One pm_command(program) per suite: hermetic::scrub_socket_vars,
hermetic::Extra::Venv, and the two node-linker overrides, applied
before cache_env::isolate and the leg's env, so a leg's own pins
win. Every package-manager child and probe in both suites now goes
through it. bundle() keeps its BUNDLE_*/GEM_*/RUBYOPT sweep
unchanged.

Evidence

• cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings pass. Both suites compile. With
  --tests, clippy on these two test targets reports the same 13
  pre-existing errors on main and on this branch (duplicate-module
  lints in the shared common/ includes).
• Live legs (pnpm, yarn_berry, yarn_classic, gem_bundler,
  pypi_uv_lock, pypi_requirements_txt, hosted and vendored) were
  run locally. Every package-manager fixture install succeeds through the new
  builder. 5 of 6 legs then stop at scan, because this sandbox's
  proxy blocks patches-api.socket.dev. The results are identical on
  origin/main (1 passed, 5 failed with the same tunnel error), so the
  network is the cause and this change isn't. CI's hosted-e2e job runs the hosted
  suite live.

CI cost

Test-only. No workflow changes, so a lean PR run keeps the same job
count and minutes (about 28 Linux jobs, ~8 min wall), before and after.

Review notes (/code-review high)

• Fixed: the first version used the full Extra::Yarn/Pnpm/
  YarnClassic/Bundle/Composer/... sweeps on every child. Those
  also remove proxy and CA settings (npm_config_https_proxy,
  YARN_HTTPS_PROXY, NPM_CONFIG_USERCONFIG) these live-registry
  suites need, and the YarnClassic sweep removes PREFIX for every
  tool. It now scrubs only what the helpers already removed, plus
  SOCKET_*.
• Fixed: kept Command::new(program) rather than tool_command, so a
  program name still resolves against the child's PATH as before.
• Not fixed (pre-existing, out of scope): vendored bundle() removes
  GEM_HOME/GEM_PATH, which cache_env.rs warns breaks rvm/chruby
  hosts. The same sweep lives in e2e_vendor_gem_build.rs and
  e2e_redirect_gem_build.rs. Changing it changes where gems install,
  so it gets its own slice.
• Not fixed: the socket-patch child in run()/run_socket() gets
  only Extra::Venv beyond hermetic::command. Adding the
  crawler-relevant extras (Bundle, Composer) is a follow-up.
• Not fixed: pm_command is duplicated across the two suites. Moving
  it into common/hermetic.rs would collide with CI: hermetic env for the PTY test spawns (#823) #1530, which is
  editing that file now.

Remaining for #823

• The GEM_* sweep in the three bundle helpers (see above).
• The crawler extras on the production suites' CLI child.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W9FQvgb6aG8vSapKuKMwKY

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit fe7b67d. Configure here.}