Hatch locator: defer pyproject.toml / hatch.toml parsing out of configure()

[eleanorjboyd]

Summary

Hatch::configure (crates/pet-hatch/src/lib.rs#L130-L154, introduced by #460) reads and parses pyproject.toml + hatch.toml for every workspace directory on every configure call. Combined with the configuration write lock issue (filed separately), this disk I/O runs while holding the configuration write lock and is the largest single amplifier of the cross-platform p90 regression observed in the v1.33 insiders cohort (May 25, 2026 telemetry).

Even after the lock issue is fixed, doing per-workspace TOML I/O on every configure is wasteful: VS Code calls configure whenever workspace folders change, and pyproject.toml rarely changes between calls.

Proposed fix

• Cache parsed workspace Hatch config keyed by (workspace_path, pyproject_mtime, hatch_toml_mtime). Reuse the cached entry if mtimes are unchanged.
• Or: move the parse out of configure() entirely; do it lazily on first try_from()/find() per workspace, behind the existing workspace_virtual_dirs mutex.
• Either way, configure() itself should be O(workspace_count) stat calls, not O(workspace_count × 2) file reads + TOML parses.

Acceptance criteria

• Hatch::configure does no file reads (stats only) when workspace TOML files have not been modified since the last configure.
• Microbenchmark: configure with 10 workspaces × 2 TOML files takes < 5ms on a warm cache (currently ~50–200ms cold depending on disk).
• Functional tests from feat: add pet-hatch locator for Hatch environments (Fixes #450) #460 still pass — Hatch envs are still correctly identified.

Context

Filed in response to the Python Environments extension team's May 25, 2026 regression report. Even though the write-lock issue is the primary cause, removing per-call TOML I/O reduces tail latency for workspaces that use Hatch and prevents future regressions of the same shape. Related PR: #460.