Stale interpreter label for virtualenv showing old Python version despite executable being Python 3.14

[mamounalzyoud]

Summary
The VS Code Python extension shows a stale interpreter label (e.g., "venv (3.13.4)") for a workspace virtual environment even though the virtual environment's python.exe is Python 3.14.0 and pyvenv.cfg shows version = 3.14.0.

Environment

• VS Code: 1.107.1 (Windows)
• Python extension: v2025.20.1
• Pylance: v2025.10.4
• Project: MeemSaaS (Django)
• Workspace path: D:\VScode Projects\MeemSaaS
• Virtualenv path showing stale label: D:\VScode Projects\MeemSaaS\backend\venv\Scripts\python.exe (UI label: venv (3.13.4))
• Actual python: D:\VScode Projects\MeemSaaS\backend\venv_314\Scripts\python.exe -> Python 3.14.0

Reproduction steps

1. Create a new virtual environment using Python 3.14 and install dependencies (or replace python.exe in an existing venv).
2. Open the workspace in VS Code and set the workspace interpreter to the venv path (workspace settings or via interpreter selector).
3. Reload the window / restart VS Code.
4. Observe interpreter selector: the listed label for the selected path still shows the old Python minor version (e.g., 3.13.4) even though python --version in that path reports 3.14.0.

Expected behavior

• The interpreter selector should display the correct Python version that matches the interpreter executable (3.14.0).

Actual behavior

• The interpreter selector displays a stale label (e.g., "venv (3.13.4)").

Additional diagnostic info

• I cleared Python extension caches, fully reinstalled the Python extension and Pylance, and removed temporary metadata caches. The problem persists.
• pyvenv.cfg shows version = 3.14.0 for the new venv.
• Tests run via VS Code test runner still pick up the workspace interpreter path internally (the executable is correct), but UI labeling is inconsistent and confusing for users.

Logs / Artifacts

• I can provide VS Code logs (shared process logs, extension host logs), the pyvenv.cfg files, and a screenshot showing the stale label if helpful.

Notes / Possible causes

• This may be caused by caching interpreter metadata (stored label/metadata not invalidated when venv is updated in-place or when Python minor version changes without changing venv path).

Please let me know what additional logs or steps you'd like me to collect. Thanks!