fix: resolve SCM repository lookup failures on Windows SUBST drives

[TheBroken0ne]

Problem

On Windows, when a workspace is opened via a SUBST drive (e.g., D: is a substitute for C:\LOCAL), SCM-dependent features like Generate Commit Message silently fail. The SCM input box button does nothing — no error, no notification.

Root Cause

fs.realpath() does not resolve Windows SUBST drive substitutions, but git rev-parse --show-toplevel does. This creates a permanent path mismatch:

• GitLens canonical path (from git): c:/LOCAL/Applfich/Sicar/SicarSuite
• VS Code SCM path (SUBST): d:/Applfich/Sicar/SicarSuite

In findRepositoryUri(), the symlink detection code compares realpath(uri.fsPath) with uri.fsPath. Since realpath returns the SUBST path unchanged, no symlink is detected, and toCanonicalMap/fromCanonicalMap are never populated. Downstream, getScmRepository() and getOrOpenScmRepository() look up the canonical path in VS Code's SCM API, which only knows the SUBST path — the lookup fails, and the command silently returns.

Fix

Three targeted changes in cliGitProvider.ts:

1. findRepositoryUri(): After the existing fs.realpath symlink detection, added a Windows-specific else if that detects SUBST drives by comparing drive letters between the workspace URI and the git-reported repo path. Uses realpath.native() on the drive root to resolve the SUBST target and populates toCanonicalMap/fromCanonicalMap.

2. getScmRepository(): Falls back to toCanonicalMap when the canonical path doesn't match any SCM repository.

3. getOrOpenScmRepository(): Resolves the effective URI via toCanonicalMap before querying/opening the SCM repository.

Testing

Tested on Windows 11 with:

• VS Code Insiders 1.119.0
• Git 2.51.0
• SUBST drive (D: → C:\LOCAL)
• Verified Generate Commit Message works correctly after the fix