fix: stop resolve() from leaking foreign envs (e.g. hatch) into the venv collection

[StellaHuang95]

Context

@flying-sheep reported 3 related bugs, #1471, #1485 and #1491

The venvs ones both trace to the same root cause in VenvManager.resolve(). Hatch envs structurally look like venvs (they have a pyvenv.cfg), so PET classifies them as Venv and they pass through resolveVenvPythonEnvironmentPath. Until now, every successful resolve() call also mutated this.collection via addEnvironment(resolved, true). So whenever anything called resolve() for a hatch path — Python: Select Interpreter, Pylance startup, a test runner asking for execInfo, another extension querying the env — the hatch env got persisted under venv too.

The original side effect dates back to commit 9363bc1 (Oct 2024), when the extension only had system and venv managers and the author assumed any successful resolve() was a newly discovered venv worth caching. That assumption stopped being true once the API supported third-party managers.

What this PR does

One-line deletion in src/managers/builtin/venvManager.ts (plus a small whitespace touch-up):

 if (resolved) {
     if (resolved.envId.managerId === `${PYTHON_EXTENSION_ID}:venv`) {
-        // This is just like finding a new environment or creating a new one.
-        // Add it to collection, and trigger the added event.
-        this.addEnvironment(resolved, true);
-
         // We should only return the resolved env if it is a venv.
         return resolved;
     }
 }
 return undefined;

resolve() is now a pure query: "given a path, are you the manager for it?" It still returns the resolved env (every consumer of resolve() keeps working), it just stops mutating state.

What this PR does not fix (follow-ups)

Three layers of bug were identified; this PR ships Layer 1 only.

• Layer 1 (this PR): resolve() side-effect leaks foreign envs into venv. Fixed.
• Layer 2 — PET cannot tell hatch envs from regular venvs. PET's Venv kind is structural (it triggers on pyvenv.cfg alone), so cross-manager overlap is expected for any tool that produces pyvenv.cfg-shaped envs (hatch in path = ".venv" mode, tox, nox, custom scripts). Needs a PET-level fix; tracking issue to be filed upstream against microsoft/python-environment-tools.
• Layer 3 — ruff and ty don't react to per-workspace env changes from this extension. Both subscribe only to api.environments.onDidChangeActiveEnvironmentPath (the legacy global-only event), not to our pythonEnvsApi.onDidChangeEnvironment.

[eleanorjboyd]

From what I can tell the PR is a valid defensive fix, but the root cause is that PET has no concept of Hatch environments. Since hatch envs have pyvenv.cfg, the Venv locator here claims them. We would need to add Hatch as supported in PET.

This fix is still useful as defense-in-depth (resolve shouldn't mutate state), let me look at this more to see if we still want this PR then, in addition to any PET changes.

[flying-sheep]

the root cause is that PET has no concept of Hatch environments. […] We would need to add Hatch as supported in PET.

Hatch environments are usually regular venvs that exist in specific locations, but not always. Hatch can use any kind of environment via plugin, e.g. you could make Hatch create conda envs instead, or docker images.

So I’d phrase that more generally: PET has no concept of env managers that manage a specific subset of envs of a known type – in other words, project-aware env managers like Hatch should be able to claim certain envs with a higher specificity than more generic / base env managers (which aren’t project-aware).

PS: don’t you have the same issue with Poetry already? It also just creates regular venvs, right?