Use normalizePath for cross-platform path comparisons on Windows

[Copilot]

Several path-equality checks used path.normalize() — or worse, compared path.resolve() output against path.normalize() output. On Windows these differ in drive-letter case and slash direction, causing settings/override and project matching to silently fail.

All affected comparisons now route through the existing normalizePath() helper (slash-normalized + Windows case-folded) on both sides.

Changes

• settingHelpers.ts / interpreterSelection.ts — fixed the core bug: comparisons of the form path.resolve(ws, s.path) === path.normalize(project). Both sides now normalized, fixing pythonProjects override lookups (env/package manager resolution, add/remove/rename) on Windows.
• projectManager.ts, creators/existingProjects.ts, creators/autoFindProjects.ts, terminal/terminalManager.ts, views/utils.ts — migrated remaining equality checks and map keys to normalizePath() for case-insensitive matching.
• Left untouched — non-comparison uses of path.normalize() (drive-root/depth validation, dirname manipulation, fileNameUtils which depends on path.sep).
• Added unit tests for views/utils.removable covering Windows drive-case/slash equivalence and POSIX case-sensitivity.

Example

// before — resolve() adds drive letter, normalize() does not; mismatch on Windows
const pwPath = path.normalize(e.project.uri.fsPath);
overrides.findIndex((s) => path.resolve(w.uri.fsPath, s.path) === pwPath);

// after — consistent normalization on both sides
const pwPath = normalizePath(e.project.uri.fsPath);
overrides.findIndex((s) => normalizePath(path.resolve(w.uri.fsPath, s.path)) === pwPath);

The findEnvironmentByPath methods named in the issue already use normalizePath(); this change extends that convention to the remaining comparison sites.

Fixes #1181