resolve hangs for tens to hundreds of seconds on Windows for invalidated cached paths

[eleanorjboyd]

Summary

The Python Environments extension team's May 25, 2026 telemetry shows pet.resolve p90 > 200s (p95 > 350s) for the cache_stale cohort on Windows v1.33 — paths that PET reports as invalid when the extension passes a cached path for resolution. 8500+ sessions affected over 7 days.

We do not yet know which code path stalls. Top hypotheses:

1. Windows Store stub on a vanished package. Cached path ~/AppData/Local/Microsoft/WindowsApps/python.exe belongs to an uninstalled Store install. try_from may fall through to a resolve_executable that spawns the stub, which blocks on Store activation.
2. norm_case on a non-existent path under Defender. GetLongPathNameW can stall for tens of seconds on suspicious or quarantined paths.
3. Retry loop in resolve_symlink or a locator's try_from when the target is gone.

Tasks

• Read handle_resolve and every Locator::try_from looking for unbounded loops, blocking spawns, or symlink chains.
• Add per-step timing to resolve (already partially present — extend with try_from_ms per locator and norm_case_ms).
• Coordinate with the extension team for per-call path-prefix slicing of slow tails (Windows Store vs registry vs pyenv vs conda).
• Once root cause found, add a hard internal timeout on the offending step (in addition to the extension-side RPC timeout).

Acceptance criteria

• resolve for a non-existent path returns within 1 second on Windows under default Defender configuration.
• Regression test using a tempdir with a since-deleted symlink target.