fix: Windows py-launcher full-version matching for python_full_version in Pipfile

[matteius]

Summary

Fixes two remaining bugs from #5893 that survived the #6360 refactor, causing pipenv install (from a Pipfile with python_full_version) and pipenv --python 3.11.9 to fail on Windows even when the requested Python was installed and visible to py --list-paths.

Root causes

Bug 1 — find_python_from_py_launcher() parser skipped non-default versions

py --list-paths output looks like:

 -V:3.12 *        C:\...\Python_3_12\python.exe   (default — 3 tokens)
 -V:3.11          C:\...\Python_3_11\python.exe   (non-default — 2 tokens)

The function used split(None, 2) then checked if len(parts) < 3: continue. Non-default entries (no *) only produce two tokens, so every non-default Python installation was silently skipped.

Fix: require len(parts) >= 2 and take parts[-1] as the executable path in all cases.

Bug 2 — PyLauncherFinder stored only major.minor, breaking patch-level searches

py --list-paths only reports major.minor (e.g. 3.11). The finder stored patch=None. When searching for 3.11.9 (derived from python_full_version = "3.11.9" in the Pipfile), PythonInfo.matches(patch=9) evaluated None == 9 → False and returned no result.

Fix: query each discovered executable for its real version string (e.g. 3.11.9) via get_python_version() so that full-version lookups succeed. Falls back gracefully to major.minor if the executable can’t be queried.

The Bug 2 fix is also submitted upstream as sarugaku/pythonfinder#166.

Scenarios now fixed (per @mjhalwa's test matrix from the issue)

Scenario	Before	After
pipenv install from Pipfile with python_full_version = "3.11.9"	❌	✅
pipenv install --python 3.11.9	❌	✅
pipenv install --python 3.11	✅	✅
pipenv install from Pipfile with only python_version = "3.11"	✅	✅

The checklist

Fixes #5893

• Associated issue
• A news fragment in the news/ directory (news/5893.bugfix.rst)

---

Pull Request opened by Augment Code with guidance from the PR author