feat: pre-warm environment manager caches during activation and background refresh

[eleanorjboyd]

Managers don't scan on registration- initialize() only runs when a consumer first calls getEnvironments() making the whole discovery process lengthly. Every step is sequential and lazy. On a large filesystem or slow disk this is 10–30 seconds of real time with the user watching an empty interpreter picker.

The Python extension avoids this by starting discovery in the NativePythonFinderImpl constructor, so results begin streaming before other exts makes its first call.

[Copilot]

Pull request overview

This PR aims to speed up environment discovery by “pre-warming” caches early: triggering PET/native discovery immediately and forcing initial manager environment lists to populate before initial environment selection runs.

Changes:

• Start a background PET refresh as soon as NativePythonFinderImpl is constructed to warm the native cache.
• During activation, pre-fetch (getEnvironments('all')) from the system and venv environment managers before applying initial environment selection.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/managers/common/nativePythonFinder.ts	Triggers an early background refresh to warm PET/native discovery cache.
src/extension.ts	Adds activation-time pre-warm calls to system/venv managers prior to initial environment selection.

Comments suppressed due to low confidence (1)

src/extension.ts:559

• Same issue as above: getEnvironmentManager(...)?.getEnvironments('all').catch(...) will fail type-checking and can throw at runtime if the manager is undefined. Ensure the .catch(...) is only invoked when a Promise is returned (e.g., ?.getEnvironments('all')?.catch(...) or by using a conditional / Promise.resolve() fallback).

                envManagers
                    .getEnvironmentManager(VENV_MANAGER_ID)
                    ?.getEnvironments('all')
                    .catch(() => {}),