Fix tsconfig include silently dropping files that differ only by base-name case

[Copilot]

On case-insensitive file systems, tsconfig.json include wildcards could silently drop a source file whose base name differs only in case from another file (e.g. src/brand.ts and src/Brand.tsx). No diagnostic was produced — the file simply never entered the program.

Root cause

• The extension-priority de-duplication logic (hasFileWithHigherPriorityExtension, removeWildcardFilesWithLowerPriorityExtension in tsconfigparsing.go) is meant to drop a file's compiled output (.d.ts, .js) when its source (.ts, .tsx) is also present.
• It located candidates by folding the whole file path through a case-insensitive canonical key. That fold conflates unrelated files whose base names merely differ in case (brand.ts vs Brand.tsx), causing one to be treated as the other's output and dropped.

Fix

• Added a shared getExactFile helper that, after a canonical-key lookup, requires the stored entry's file name to be an exact, case-sensitive match before treating it as a priority conflict.
• Applied it in both the "higher priority" check and the "remove lower priority" cleanup, so:
  • Files differing only by case are never conflated — both stay in the program.
  • Legitimate same-name priority resolution is unchanged (foo.ts still wins over foo.d.ts / foo.js).

// tsconfig.json
{ "include": ["src/**/*"] }

src/brand.ts    // export const brand = "ok";
src/Brand.tsx   // now correctly included instead of silently dropped

Tests

• Regression test reproducing the reported scenario against a simulated case-insensitive file system.
• Test guarding the still-intended same-base-name priority behavior (foo.ts over foo.d.ts/foo.js).
• Direct unit tests for the new getExactFile helper.

• Fixes tsconfig include silently drops Foo.tsx when foo.ts exists, on a case-insensitive filesystem #64098