Cross-session cache misses on every fresh remote (SSH / WSL / dev container / codespace)

@eleanorjboyd がすでに取り組んでいます。

2026年6月17日 から。

## Problem

The cross-session cache for the discovered global system Python (PR #1455) lives in `context.globalState`. In remote scenarios, `context.globalState` is scoped to the remote machine, not the local one. As a result, the cache never primes on a fresh remote and every first connection to a new SSH host, dev container, codespace, attached container, or WSL distro starts cold and falls through to a full PET refresh on the foreground env-selection path.

This also affects the local case any time `globalState` is wiped (e.g. extension reinstall, profile reset).

## Current behavior

- [`getSystemEnvForGlobal()` / `setSystemEnvForGlobal()`](../../src/managers/builtin/cache.ts) read/write `SYSTEM_GLOBAL_KEY` via [`getGlobalPersistentState()`](../../src/common/persistentState.ts), which wraps `context.globalState`.
- `getGlobalPersistedPath` is wired into `tryFastPathGet` ([fastPath.ts](../../src/managers/common/fastPath.ts)) for the system-Python path. When `globalState` is empty the fast path returns `undefined` and registration falls through to the slow path.
- Workspace-scoped paths use `setSystemEnvForWorkspace` / `getSystemEnvForWorkspace`, which write to `context.workspaceState` (keyed on workspace folder fsPath) — that path is unaffected.

## Why it matters

Every time a user connects VS Code to a new remote (or reopens after the remote `globalState` is reset), the foreground env-selection path waits on a fresh PET refresh instead of validating a cached path. This is the dominant remaining hang scenario on Linux based on our most recent investigation, and ssh-remote, WSL, and dev-containers are all affected.

## Acceptance criteria

- [ ] On a workspace where the global system Python has been resolved at least once, opening the same workspace folder in a fresh VS Code session on the same remote hits the cache without a PET refresh.
- [ ] On a brand-new workspace folder on the same remote, behavior is unchanged from today (cache miss → PET refresh).
- [ ] On a brand-new remote with a brand-new workspace folder, behavior is unchanged from today (option 1 doesn't claim to fix this case — option 2/3 would).
- [ ] No regression to existing telemetry: `global_env.cache` continues to emit `hit` / `miss` / `stale` correctly.
- [ ] No regression to the workspace-scoped fast-path (`getSystemEnvForWorkspace` users).
- [ ] Unit tests covering: workspaceState-primary lookup, fallback to globalState, both write paths, and stale-path invalidation through both layers.

## Related

- PR #1455 — original cross-session cache.
- PR #1564 — cheap `fs.access` check on persisted paths in fast-path resolution. (this helped fix the regression which the prior PR introduced)