Add experimental managed Python environment provisioning with uv

[anton-107]

Changes

Stacked on #1905 (base branch is dbconnect-env-quick-wins); review that one first. Experimental, default off.

Second part of the "Run/Debug with Databricks Connect should just work" effort (CUJ findings and design note in #1905). With databricks.experiments.optInto: ["python.managedEnvironment"], clicking Run/Debug with Databricks Connect in a fresh project provisions everything behind a single cancellable progress notification — no manual Python environment steps:

1. Resolve the target from the selected compute via resolveComputeTargetSpec (serverless 17.3 → Python 3.12 + databricks-connect==17.3.*; clusters → DBR-matched versions).
2. Locate uv (UvBinaryProvider): PATH first (corp installs keep their proxy/mirror config), then a previously downloaded copy, then a pinned, SHA256-verified download from GitHub releases into globalStorageUri (macOS/Linux/Windows, x64+arm64).
3. Ensure the interpreter: uv python find, falling back to uv python install (uv downloads python-build-standalone builds).
4. Create .venv with uv venv --seed — seeded pip keeps the extension's existing pip list introspection and other tooling working.
5. Install dependencies: databricks-connect matched to the compute, nbformat, then the project's own requirements*.txt / pyproject.toml dependencies.
6. Select the interpreter in the MS Python extension (refreshEnvironments + updateActiveEnvironmentPath), so run, debug (pinned in Fix Python environment issues in the Databricks Connect run/debug flow #1905), terminal and the status bar all agree.

Respecting user-managed environments

• An environment that already satisfies the checks is selected, never modified.
• Environments created by this flow are tagged with .venv/databricks.json and may be repaired (reinstall deps) or recreated (wrong Python) silently.
• A foreign .venv is never modified or deleted without an explicit prompt (Install into .venv / Recreate .venv / Set up manually). "Set up manually" and unsupported computes fall back to the existing per-step flow unchanged.

Failure UX

Failures are classified — networkBlocked, pythonUnavailable, uvUnavailable, disk, cancelled — into specific, actionable messages with Retry / Show Logs / Set up manually buttons. Custom indexes are honored: UV_INDEX_URL passes through, PIP_INDEX_URL is mapped to UV_INDEX_URL, and pip.conf/pip.ini index-url is parsed and forwarded (uv doesn't read pip config). The network error message points at HTTPS_PROXY/UV_INDEX_URL/UV_PYTHON_INSTALL_MIRROR.

Telemetry

New managedEnvironmentSetup event with one record per funnel step (uvAcquire, pythonInstall, venvCreate, depsInstall, interpreterSet) plus a total, carrying success, duration, failure class, compute type and venv disposition — so funnel drop-off becomes measurable.

Integration

The only behavioral hook is in EnvironmentCommands._setup: when the experiment is on and the failing steps are limited to the python environment/dependencies (shouldProvision), it runs the provisioner; otherwise (and always with the flag off) the existing per-step action loop runs byte-identically. Cluster/UC problems keep the manual flow.

Risks / known limitations

• uv python install downloads from GitHub; fully offline networks need UV_PYTHON_INSTALL_MIRROR (called out in the error message). Bundling uv into the vsix was deliberately deferred (see design note in Fix Python environment issues in the Databricks Connect run/debug flow #1905).
• The uv download URL/checksum format is validated for the pinned UV_VERSION only; bumps should be deliberate.
• pyproject.toml dependency-groups (beyond [project].dependencies) are a fast-follow.

Tests

• computeTargetSpec.test.ts: spec resolution matrix (serverless, clusters, wildcard/unsupported DBR).
• EnvironmentProvisioner.test.ts: command sequences for fresh create / repair / recreate with a fake exec recorder on real tmp dirs; marker-file semantics; foreign-venv prompt branches (incl. "never touch on manual"); cleanup of half-created venvs on failure; failure classification from real uv/pip stderr shapes; PIP_INDEX_URL→UV_INDEX_URL mapping and pip.conf parsing; win32/posix interpreter paths.
• UvBinaryProvider.test.ts: PATH short-circuit, cached binary reuse, checksum-mismatch rejection, failed-download handling.
• EnvironmentCommands.test.ts: shouldProvision matrix; provisioner never invoked with the flag off.
• yarn test:lint and yarn test:unit pass (225 passing).

Manual validation script (macOS, fresh profile): databricks bundle init default-python, select serverless, opt into the experiment, click Run with Databricks Connect → single progress notification (uv downloads Python 3.12, creates .venv, installs databricks-connect==17.3.*) → file runs; Debug hits breakpoints with the same interpreter. Negative: UV_INDEX_URL=http://blocked.example → actionable network error with Retry.

This pull request and its description were written by Isaac.

[anton-107]

Follow-up commit 49437c3 addresses self-review findings: archive extraction now uses tar on all platforms (no PowerShell string interpolation), environment discovery is force-refreshed after venv creation, uv exec buffer raised to 128MiB, network-failure classification patterns anchored, provisioner errors outside its steps fall back to the manual flow, and the installer's suggested-version logic now delegates to resolveComputeTargetSpec. Unit suite: 227 passing.

Known limitation worth calling out for review: the uv download uses Node's fetch, which does not honor HTTPS_PROXY — behind a mandatory proxy the PATH-installed uv (or manual install, as the error message suggests) is the working path. Happy to wire a proxy agent if you'd rather have that in this PR.

This comment was written by Isaac.