Improve PEP 723 inline-script env setup (failure messages + uv shim fix)

[Stella Huang (StellaHuang95)]

Summary

Two related fixes for the (internally-flagged) PEP 723 inline-script environment feature, found while manually testing the "Set up environment for this script" CodeLens.

1. Surface inline-script setup failures instead of failing silently

Previously, clicking the CodeLens and having setup produce no environment was silent — the reason lived only in the Python Environments output log. The interactive setup command now surfaces an actionable message:

• a warning for the no-compatible-python case, with a note when requires-python is an exact two-segment pin like ==3.11 (PEP 440 treats it as exactly 3.11.0, which is often not installable);
• a generic "see the output" error for other failures;
• silence when the user declined the Python install, or when an environment was built but intentionally not associated (the script's metadata changed mid-setup).

The env manager records the setup outcome (failed reason or benign skip) on the shared InlineScriptRoutingRegistry as a diagnostic side-channel; the setup command reads it once to choose the message. Only the interactive CodeLens flow shows messages — bulk and programmatic environment creation are unaffected.

2. Build inline-script venvs from the real interpreter, not a uv shim

When the extension auto-installs a Python via uv, discovery can select uv's version-named launcher shim on PATH (e.g. ~/.local/bin/python3.8.exe) as the base interpreter. Passing that shim to uv venv --python <shim> fails for Python ≤ 3.10 — uv can't inspect it; the launched interpreter can't locate its standard library and aborts with No module named 'encodings'. (Python 3.11+ tolerates it.) The real interpreter in the uv-managed install folder works for every version.

createWithProgress now resolves the base via a new getBaseInterpreterForVenv: when the environment's executable lives outside its own sysPrefix (a launcher/shim), it uses the interpreter inside the prefix (<sysPrefix>/python.exe or bin/python[3]), falling back to the original executable if none exist. Applied to both the uv venv and python -m venv paths. It is a no-op for normal interpreters, and it also prevents a shim-built venv from recording a pyvenv.cfg home whose python.exe does not exist (which would otherwise make the base-existence check report the base as missing on every reuse).

Testing

• npm run compile-tests + unit suite: 2001 passing / 0 failing (3 new tests for getBaseInterpreterForVenv).
• Manually verified on Windows: uv venv --python <shim> fails for 3.8 while uv venv --python <real interpreter> succeeds; the failure boundary is exactly Python ≤ 3.10.

[Eduardo Villalpando Mello (edvilme)]

Can this maybe use the new PythonVersion class for pargins and extracting major/minor?