python: add python.getEnvironmentHealth command

[austin3dickey]

Fixes #14694. Adds a python.getEnvironmentHealth command that produces a JSON report on whether the current Python setup is ready to start a session, following Positron's recommendations. The command runs four checks in dependency order and short-circuits (marking later items skipped) when an earlier one fails:

1. discovery - Positron can discover Python environments (the PET locator is operational).
2. pythonInstalled - a supported Python (3.9-3.14) is installed.
3. dedicatedEnvironment - a dedicated (workspace-local or named) virtual environment is available.
4. environmentReady - the would-be interpreter resolves and runs, its version is supported, its Jupyter kernel (ipykernel) is usable, and (on Apple silicon) it is not an x64 build running under Rosetta.

Each item returns a pass / warn / fail / skipped status, a localized summary and detail, and an optional fix (a command id, JSON-safe args, and a button label) that a frontend can invoke to resolve the problem. The full result is logged as JSON to the Python output channel.

There is no UI yet; this PR is the backend groundwork. The command doubles as a developer probe run from the Command Palette ("Python: Print environment health report to Output"). A frontend to surface the report will come in a follow-up.

Supporting changes:

• NativePythonFinder now tracks lastDiscoveryError so the discovery check can tell a broken locator apart from an empty one; it is set on process/connection/refresh errors and cleared on a successful refresh.
• python.createEnvironmentAndRegister now accepts a URI-string workspaceFolder (new CreateEnvironmentAndRegisterOptions) so a health-check fix can pass it across the command boundary; it rehydrates the string to a WorkspaceFolder internally.
• isBaseCondaEnvironment is exported from environmentTypeComparer for reuse.

Release Notes

New Features

• N/A

Bug Fixes

• N/A

Developer-facing groundwork; no user-visible feature yet. The palette command only logs a diagnostic report to the Output panel.

Validation Steps

@:interpreter

This command has no dedicated e2e coverage yet (no UI). The logic is covered by unit tests; run them from extensions/positron-python:

npm run test:unittests -- --grep "Python Environment Health"
npm run test:unittests -- --grep "Positron Create Environment APIs"

Manual smoke test via the Command Palette ("Python: Print environment health report to Output"), confirming the Python output channel shows the JSON report and ok reflects the state:

1. No folder open, with a dedicated env discovered elsewhere -> dedicatedEnvironment warns. Open a folder that uses a venv -> all items pass, ok: true.
2. Folder open using a global/system/base interpreter -> dedicatedEnvironment fails with a "Create Python Environment" fix.
3. Folder open using a workspace venv on a supported Python -> all items pass.
4. (Apple silicon) Interpreter is an x64 build -> environmentReady warns about Rosetta with an "Install Native Python" fix.
5. Set python.allowUvPythonInstall to false and confirm the install-Python fixes are omitted (discovery/install checks still run).

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:interpreter @:console @:new-folder-flow

Why these tags?

Tag	Source
@:critical	Always runs (required)
@:interpreter	PR description
@:console	Changed files
@:new-folder-flow	Changed files

More on automatic tags from changed files.

^{readme  valid tags}

[austin3dickey]

I still want to go through and try this on Mac/Windows/Linux/Web.

[austin3dickey]

Sorry, please hold. I want to look into a bit of weirdness where I have a workspace open without a venv and the health check was completely green, pointing to a global python.

[austin3dickey]

I have a workspace open without a venv and the health check was completely green, pointing to a global python

This is because my global python was classified as uv and this PR doesn't handle distinguishing the base uv Pythons from venv uv Pythons. Instead of adding logic to handle that here, I think it makes more sense to classify base uv Pythons as Global: #14912

(We've already received feedback that this would make more sense.)