When a project's repo-relative path case doesn't match what git records (e.g., project reports path as a/b but git records it as A/b), the managed git implementation fails to walk the tree when searching for version.json files. This results in a version height of 0 instead of the correct value.

Root Cause

The issue was in ManagedVersionFile.GetVersion() at line 164 where GetTreeEntry() uses case-sensitive matching to find directory entries. When the path casing doesn't match git's records, the tree walk fails and no version.json file is found.

Solution

This PR implements case-insensitive fallback logic for the managed git implementation:

1. Git Config Reading: Added ReadIgnoreCaseFromConfig() method to read core.ignorecase setting from git configuration files (both repository-specific and global)

2. Case-Insensitive Tree Matching: Extended GitTreeStreamingReader.FindNode() with an optional ignoreCase parameter that performs ASCII case-insensitive comparison

3. Fallback Logic: Modified GitRepository.GetTreeEntry() to attempt case-insensitive matching when core.ignorecase=true and the initial case-sensitive search fails

Example

// Before: This would fail if git recorded the path as "MyProject" but code used "myproject"
var versionOptions = context.VersionFile.GetVersion("myproject");  // Returns null

// After: With core.ignorecase=true, this now works correctly
var versionOptions = context.VersionFile.GetVersion("myproject");  // Returns version info

Testing

• Added comprehensive unit tests covering case-sensitive, case-insensitive, and edge case scenarios
• All existing tests continue to pass, confirming no regressions
• The LibGit2 implementation already handles this correctly via libgit2's native case-insensitive support

Fixes #618.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.