fix: identify bare repo via GIT_DIR for safe.bareRepository=explicit

[MattKotsenas]

This PR addresses two distinct bugs that happen to co-occur on Windows under agent shells.

Bug 1: safe.bareRepository=explicit breaks every grove command that touches the bare repo

Grove invokes git by setting current_dir to the bare repository path, relying on git's CWD-based repo discovery. That discovery is disabled when safe.bareRepository=explicit is in effect (git-config(1)):

$ grove add feature-x
Error: ... fatal: cannot use bare repository '...' (safe.bareRepository is 'explicit')

This setting is injected on every spawned shell by GitHub Copilot CLI. It sets GIT_CONFIG_COUNT=1 + GIT_CONFIG_KEY_0=safe.bareRepository + GIT_CONFIG_VALUE_0=explicit so the agent can't be tricked into operating on a stray .git directory it didn't intend to touch. Affected commands: grove add, grove list, grove sync, grove prune, grove remove (anything that routes through git_raw), plus the post-clone config call in clone_bare_repository.

Reproduction

$env:GIT_CONFIG_COUNT = "1"
$env:GIT_CONFIG_KEY_0 = "safe.bareRepository"
$env:GIT_CONFIG_VALUE_0 = "explicit"
grove list  # fatal: cannot use bare repository '...' (safe.bareRepository is 'explicit')

Bug 2: git-for-Windows rejects \\?\ extended-length paths in GIT_DIR and --git-dir

Switching to GIT_DIR exposed a separate latent bug. discover_bare_clone returns the bare repo path via Rust's std::fs::canonicalize, which on Windows always emits paths with the \\?\ extended-length prefix (documented stdlib behavior). Git accepts \\?\ paths as a process working directory because Win32 round-trips them transparently and git never parses the CWD as a string. But supplied via GIT_DIR or --git-dir, git's portable path parser rejects the prefix as malformed input:

fatal: not a git repository: '\\?\D:\repo\bare.git'

This is independent of path length and independent of core.longpaths. Verified with an 87-character path and -c core.longpaths=true explicitly forced.

Root cause

This is fundamentally a wart in git-for-Windows: \\?\D:\foo is a valid Windows path that every Win32 path API accepts, but git's path parser doesn't recognize the prefix. The corresponding Rust-side discussion (rust-lang/rust#42869, open since 2017, 60+ comments) is downstream of this; Rust returns the canonical Windows form from canonicalize, and tools that don't accept it (cl.exe, git, etc.) force every Rust caller to post-process. The community workaround is the dunce crate, which strips \\?\ when safe.

Why GIT_DIR and not -c safe.bareRepository=all

The override approach would mechanically work (later -c wins over GIT_CONFIG_*-supplied config), but it actively subverts the hardening signal the agent set deliberately. GIT_DIR cooperates with the policy, which is what explicit is asking for. It also future-proofs against similar policies (safe.directory, etc.) without each requiring its own override.

Fix

Reuse the existing normalize_path_for_git (added in commit 5fb0067 for the same root issue on worktree-path args). Stripping \\?\ loses extended-length-path support for >260-char paths, but that's the same tradeoff already accepted for worktree-path args, so this PR doesn't introduce a new regression.

Additionally, rather than scatter GIT_DIR-vs-current_dir decisions across callsites, this PR routes every Command::new("git") through one helper:

enum GitTarget<'a> {
    BareRepo(&'a Path),  // existing bare repo → GIT_DIR (+ \\?\ strip)
    WorkTree(&'a Path),  // inside a worktree → current_dir
    Unbound,             // no repo target yet (e.g. clone, --version)
}

fn build_git_command(target: GitTarget, args: &[&str]) -> Command { /* ... */ }

All four pre-existing callsites are migrated:

Callsite	Target
git_raw (the main bare-repo workhorse)	BareRepo
clone_bare_repository initial clone	Unbound
clone_bare_repository post-clone config	BareRepo
complete_worktree_info status check	WorkTree

This provides a uniform policy that prevents drift across callsites and simplifies test assertions about the command.