[Bug] Python Path Resolution Ignores Activated Virtual Environments on Windows

### Version

4.0.6821

### Description

The Azure Functions Core Tools' Python path resolution logic has significant issues on Windows that make it difficult to use virtual environments reliably. The current implementation prioritizes global Python installations and the Python Launcher for Windows (`py.exe`) over activated virtual environments, causing modules installed in the virtual environment to be unavailable during local function execution.

### Steps to reproduce

# Current Behavior

When running func host start, the tool ignores both:

* The currently activated virtual environment
* The azureFunctions.pythonVenv setting in VSCode settings.json

The path resolution function (GetEnvironmentPythonVersion()) searches for Python in this order:
csharpCopy1. Environment variable "languageWorkers:python:defaultExecutablePath"
2. Windows Python Launcher ("py")
3. "python3"
4. "python"
5. Specific versions (python3.6-python3.12)

On Windows, this causes issues because:

The Windows Python Launcher ("py") is checked before virtual environment paths
The resolution order doesn't consider the active virtual environment's priority
No logging of which Python executable path was actually selected

## Impact

* Developers can't use isolated virtual environments effectively
* Installed packages in virtual environments are not found
* Development/production parity issues
* Workarounds (like copying python.exe to py.exe in venv) are hacky and fragile

## Proposed Solution

Modify the Python path resolution logic to:
```csharp
var versions = new List
{
await pythonGetVersionTask, // Check "python" first (catches activated venv)
await python3GetVersionTask,
await pyGetVersionTask, // Move Windows Launcher lower in priority
// ... rest of version checks
};
```
2. Add verbose logging to show:

* Full path of selected Python executable
* All candidates considered and their paths
* Why each candidate was accepted/rejected

3. Respect the VSCode azureFunctions.pythonVenv setting by adding it to the resolution order

# Steps to Reproduce

1. Create new Python Azure Function project
2. Create virtual environment: python -m venv .venv
3. Activate virtual environment: .venv\Scripts\activate
4. Add custom package to requirements.txt
5. Install requirements: pip install -r requirements.txt
6. Run func host start --verbose
7. Observe that global Python is used instead of venv Python

##Environment

OS: Windows 11
Azure Functions Core Tools: 4.x
Python: 3.11
VSCode: Latest

## Related Issues

#3042
#2041

## Additional Context
This is a blocker for Python development with Azure Functions on Windows, as it prevents reliable local development with virtual environments. The current workarounds (copying executables, setting environment variables) are not suitable for production environments or team development scenarios.
/cc @vrdmr @ejizba

Start with GetEnvironmentPythonVersion() and trace how the candidate executable tasks are assembled on Windows. Reproduce the issue with an activated .venv using `func host start --verbose`, then verify that the selected executable, considered candidates, and rejection reasons are logged and that the virtual environment and azureFunctions.pythonVenv setting are respected.

Written by the indexing model from the issue text.