Dedicated support for the Python Environment Extension

[MichaReiser]

Summary

This PR adds dedicated support for the Python Environment extension.

There are three operations for which we integrate with the Python extension and the Python Environment extension:

• Given a path to a Python interpreter, resolve to its executable.
• Resolve the selected virtual environment
• Restart the server when the selected virtual environment changes

However, the way our code is structured today didn't make this very clear. Which ultimately resulted in a couple of refactors:

• Make the outlined API above more explicit
• Introduce a new EnvironmentProvider interface to abstract over different environment providers. For now, there's an implementation for both the Python Extension and the Python Environment extension, but I foresee a third implementation that uses the bundled ty bundle (or uv!) to find the virtual environment.
• The Python Environment extension is way more trigger-happy when it comes to firing the onDidActiveEnvironmentChange event, which resulted in a lot of unnecessary server restarts. That's why I decided to beef up our server restart logic to avoid restarts unless the environment change results in the extension picking up a different ty binary or the environment actually changed.
• I changed ty.interpreter from string[] to string. We always ignored all paths except the first. Making this a string is more honest.
• We no longer abort if the Python interpreter is too old. Instead, we use the global or bundled ty executable.

It should be possible to split some of those changes into separate PRs, but I didn't do so because all of them were motivated by getting to a working Python Environment extension integration.

Don't worry, you don't need to review 2k lines. About 1400 lines are from the Python Environment extension's type definitions.

Fixes astral-sh/ty#3021

Test Plan

I tested

• Multi workspace folders
• when ty.interpreter is set
• when ty.path is set
• when the virtual environment contained a ty binary

[MichaReiser]

We now resolve this during server startup instead of when resolving the setting. This feels more "natural"

[MichaReiser]

activate runs exactly once. It's not clear to me how we would get there with a restart in progress

[MichaReiser]

I created a separate restartServer function so that it becomes clearer which work is necessary to serialize restart events.

[MichaReiser]

The changes here are so that we can have nice logging like this:

2026-05-01 14:42:00.499 [info] Checking whether the active Python environment changes the ty executable.
2026-05-01 14:42:00.548 [info]      Resolving active Python environment for workspace: 'file:///Users/micha/astral/test'
2026-05-01 14:42:00.548 [info]      Resolved Python executable for ty lookup: '/Users/micha/astral/test/.venv/bin/python'
2026-05-01 14:42:00.575 [info]      Resolved ty executable from Python environment: '/Users/micha/astral/test/.venv/bin/ty'
2026-05-01 14:42:00.576 [info] Resolved ty executable changed from '/Users/micha/astral/ty-vscode/bundled/libs/bin/ty' to '/Users/micha/astral/test/.venv/bin/ty'; restarting ty.

This matches the console.group and console.groupEnd APIs