Run workspace grep through the trusted Git executable

[beardthelion]

Fixes #395.

Workspace file discovery refuses to resolve git from PATH: trustedGitExecutable stats a fixed list of absolute paths and returns null rather than fall back. Grep did the opposite, passing a bare "git" as argv0 at gitIgnoresRoot, gitGrepTrackedMatches, and gitGrepTrackedCounts, with cwd set to the search root. One grep_files call ran a planted PATH git twice; the same workspace searched through discovery never touched it.

The three sites now take the executable discovery already selects, and grep skips the git backend when none is available, which is the orelse break :git shape discoverWithStop uses for its null case. Semantics are otherwise unchanged: force_fallback still suppresses the check-ignore spawn, and an ignored root still reaches the same fallback.

trustedGitExecutable becomes pub. runGitForTest in this file resolves Git the same way, which is what lets the argv guard key on the bare literal rather than on an argv shape.

Verification

Each guard was run against the mutation it exists to catch.

Mutation	Expected	Caught by
check-ignore argv0 -> bare name	RED	spawn tests + argv scan
git grep -n argv0 -> bare name	RED	collect spawn test + argv scan
git grep --count argv0 -> bare name	RED	count spawn test + argv scan
null guard -> orelse "git"	RED	refusal test
add a new bare-name spawn carrying no usual flags	RED	argv scan
both public wrappers pass null	RED	wrapper test
either wrapper alone passes null	RED	wrapper test

The end-to-end test drives the built binary against a fake gateway with a git planted first on PATH. grep_files returns its match while the plant records nothing. The terminal control runs git --version through the same PATH and asserts the plant did record a run, so an override that never reached the child cannot read as a guard that held. Reintroducing the defect makes the grep half fail with the recorded argv.

Three of the four commits are test work because the first round of tests was not load-bearing: the spawn assertion counted runs, so adding a bare-name spawn kept it green while threading the executable to one more site turned it red, and the null-guard test passed with the guard replaced by a name.

zig build test on 88cb3da8: 8403/8458 passing on base, 8409/8464 on the branch, with the same 33 failing test names and the same 7 crashes on both. The +6 accounts for the added tests. zig fmt --check clean.

Scope

Two pre-existing gaps this does not close, both noted in #395: src/core/github/git_context.zig:37 and src/builtins/skills.zig:253 still build argv from a bare "git", and trustedGitExecutable stats with follow_symlinks = true and checks only that the candidate is a file, so an allowlisted path that is user-writable or a symlink out of the allowlist is accepted. Pinning argv0 also does not stop the workspace's own .git/config from running a program through core.fsmonitor; that is unchanged by this PR, and command_effect.zig and direct_command.zig already harden their own git spawns.

The allowlist misses some real install locations (Linuxbrew, /snap/bin, asdf/mise shims). On those machines grep now uses the Zig scanner rather than the git backend. Results are equivalent, since the untracked pass already fell back there, but it is slower on a large repo.

The e2e test covers the collect path; the count path is covered at the module seam only. Both spawn tests skip on Windows, which the allowlist supports but CI does not run.