Replace git ls-tree with projection-based folder count

[tyrielv]

Replace git ls-tree with projection-based folder count for hydration status

Summary

Replace the slow git ls-tree -r -d HEAD approach for counting total folders (used as the denominator in hydration percentage) with an in-memory projection tree walk. On a large repo with 2.8 million files (~387K directories), this reduces folder count time from ~10-25 seconds (wide variance observed in practice) to ~78ms in the mount process, and to ~2 seconds via index parsing in the unmounted fallback path.

Once this PR completes, a follow-up PR will be created to further improve the status hydration hook to use IPC with the mount's named pipe to get the cached data rather than launching gvfs health --status

What changed

Area	Change
GitIndexProjection	GetProjectedFolderCount() — walks the in-memory FolderData tree using a stack (mounted repos)
GitIndexProjection.GitIndexParser	CountIndexFolders() — parses git index v4 to extract unique directories (unmounted fallback for gvfs health)
EnlistmentHydrationSummary	CreateSummary() now takes a required Func<int> projectedFolderCountProvider parameter; GetHeadTreeCount() removed entirely
GitStatusCache	SetProjectedFolderCountProvider() — late-bound provider set by FileSystemCallbacks after GitIndexProjection is created (documented circular dependency)
FileSystemCallbacks	Wires the provider: () => this.GitIndexProjection.GetProjectedFolderCount()
HealthVerb	Fallback path uses GitIndexProjection.CountIndexFolders() for unmounted repos
Dead code removed	GetHeadTreeCount(), GitProcess.GetHeadTreeId(), GVFSConstants.TreeCount cache file constant

Threading fixes (from prior PR review feedback)

• Interlocked.Exchange for activeHydrationTask — fixes race between background thread and Dispose()
• Bounded Wait(5s) in Dispose() — prevents shutdown hang if hydration task stalls
• Compacted blank lines around ThrowIfCancellationRequested() calls

Tests

• Rewrote EnlistmentHydrationSummaryTests — 5 tests for CountIndexFolders using synthetic git index v4 binary
• Added EnlistmentHydrationSummaryContextTests — GetIndexFileCount error path + CreateSummary cancellation

Manual testing

Verified on a large repo (~2.8M files, ~387K dirs) — gvfs health --status and git status both show correct hydration percentages, updating from 6% → 11% folders after hydrating 10,000 directories.

[KeithIsSleeping]

Multi-Model Code Review

Reviewed with Claude Opus 4.6, GPT-5.3-Codex, and GPT-5.4. Note: Opus gave this PR a clean bill on the item below — this finding is from the GPT models only (2/3). Flagging for author consideration.

[KeithIsSleeping]

MEDIUM (disputed — 2/3 models flag, Opus disagrees): Folder count semantics diverge between mount path and health fallback

GetProjectedFolderCount() walks the in-memory projection tree, which is built only from entries accepted by AddIndexEntryToProjection (skip-worktree/merge-state filtered). CountIndexFolders() in the fallback path parses raw index entries and counts directories for ALL entries with no equivalent filtering.

This means the hydration denominator can differ depending on code path (mounted status-cache vs gvfs health --status fallback). It could also fall below HydratedFolderCount, causing EnlistmentHydrationSummary.IsValid to fail.

Note: Opus 4.6 analyzed this and concluded the count is correct, arguing the projection tree is the right denominator since only projected folders can be hydrated. This may be intentional behavior — flagging for author to confirm.