🐛 fix(env): strip PYTHONPATH from isolated builds

[gaborbernat]

Closes #405

When PYTHONPATH is set in the host environment, it leaks into isolated build subprocesses. The build backend and package installers then discover packages from the host instead of the isolated venv, breaking the isolation contract. 🔒 This causes hard-to-diagnose build failures when the host has incompatible package versions — for example, an old pip that lacks --use-pep517.

The fix clears PYTHONPATH in make_extra_environ() so all backend hook calls via pyproject_hooks strip it from their subprocess environment. The uv backend's install path, which explicitly passes os.environ, also gets the same treatment. Internal pip calls already use -Im (isolated mode) which ignores PYTHONPATH, so they were unaffected.

Setting PYTHONPATH to an empty string (rather than removing it) ensures the key is present in the environment dict and overrides whatever value the host had, even when the runner merges it with os.environ.copy(). Non-isolated builds (--no-isolation) are unaffected since they don't go through DefaultIsolatedEnv.

[gaborbernat]

Updated the approach per your feedback. The fix now:

1. make_extra_environ() returns PYTHONPATH: '' — this overrides the host value when pyproject_hooks' runner does os.environ.copy().update(extra_environ). An empty PYTHONPATH is treated as unset by CPython's path initialization (if pythonpath_env: is falsy for empty string), so no paths are added to sys.path.

2. _UvBackend.install_dependencies() builds the env dict by filtering out PYTHONPATH entirely (it passes env= directly to subprocess, so true removal is possible here).

No os.environ mutation, fully thread-safe. The PYTHONPATH='' approach through extra_environ is the only way to override the value without bypassing the pyproject_hooks runner (which handles stdout/stderr display for verbosity control).

[henryiii]

Okay, that's reasonable. Maybe could be a future thing to do in pyproject_hooks.