Replace GitRepository .git-internals parsing with LibGit2Sharp

[ChrisonSimtian]

Tier 1 — Replace. src/Fallout.Build/VCS/GitRepository.cs (~268 LOC) hand-parses git internals — .git/config, .git/HEAD, packed-refs — and uses a regex to crack remote URLs (HTTPS/SSH). This is the single most fragile spot found in the audit: it breaks if git changes its on-disk format.

Replace with

LibGit2Sharp — the standard .NET libgit2 binding. Eliminates manual packed-refs/config parsing and the URL regex (use Uri).

Scope

• src/Fallout.Build/VCS/GitRepository.cs — FromLocalDirectory(), GetRemoteConnectionFromUrl(), GetRemoteConnectionFromConfig()
• Keep GitRepositoryExtensions.cs (simple branch-name comparisons) as-is.

Non-breaking

Wrap LibGit2Sharp behind the existing GitRepository public surface — additive, no consumer signature changes. Target the 2026 line directly.

Acceptance

• .git file/regex parsing removed; introspection backed by LibGit2Sharp
• Public GitRepository API unchanged (verified against call sites)
• Existing VCS tests green; add cases for SSH/HTTPS/UNC remotes

From dependency-consolidation audit, 2026-06-02.

[ChrisonSimtian]

Insights from a discarded prototype (it forked the pre-rearchitecture tree, so paths are old — map to the renamed onion structure after #359).

• Package: LibGit2Sharp 0.31.0 (central version).
• FromLocalDirectory: use Repository for head/commit/branch/tags/tracked-remote/URL. Drops manual .git/config, HEAD, packed-refs parsing + the URL regex.
• Remote URL: use Uri plus a small SCP-like (git@host:path) fallback — plain Uri won't parse SCP syntax.
• Public surface stayed unchanged (no external callers of the removed internal helpers).
• Add test cases: SSH-with-port, HTTP, file://, UNC (\server\share\repo.git). Prototype: 26/26 green.

[robvanuden]

Will this make it work in worktrees as well?

[ChrisonSimtian]

Will this make it work in worktrees as well?

yes, LibGit2Sharp probably does a way better job out of the box than we could do maintaining this ourselves.
So in short, less code to maintain while also gaining new features/fixing existing bugs ;-)
Only worry atm is what if they cease development. But I think at that point we would just fork it and maintain it ourselves and return back to status quo (o: