apple: the toolchain fingerprint memo answers a stale default xcode-select selection for its whole TTL #3300

Problem

toolchainFingerprintCacheKey (packages/platform-apple/src/runner/runner-toolchain-probe.ts) keys the memoized toolchain fingerprint by commandDeveloperDir() ?? ''. When no client sets DEVELOPER_DIR, the key is '' regardless of what xcode-select currently points at. A long-lived daemon that answered a cache decision before someone ran xcode-select --switch keeps answering with the old fingerprint for up to TOOLCHAIN_FINGERPRINT_TTL_MS (10 minutes), so runner cache metadata (and the derived-path staleness decision built on it) can name the wrong toolchain during that window.

Found by Cubic review on #3298 (thread on runner-toolchain-probe.ts:136); the function is moved verbatim from runner-cache-metadata.ts (#3109 shape), so this is pre-existing, not a #3298 regression.

Candidate fixes

• Resolve the default selection once per fingerprint read (xcode-select -p is cheap next to the probes that already run) and key on the resolved dir, keeping '' only when resolution itself fails.
• Or invalidate the memo when the resolved default selection changes between reads.

Evidence to plant

• Warm the fingerprint under default selection A, switch the stubbed resolution to B, assert the next resolveExpectedRunnerCacheMetadata re-probes rather than answering from the memo (mirror the existing a toolchain read under one DEVELOPER_DIR does not answer for another test, which covers the explicit-DIR case and stays green).
• Keep the TTL-renewal and cancellation-matrix cases green: the key change must not re-probe on repeated identical reads.