perf(gitx): run git's own binary, not a launcher in front of it - #19

Reviewer notes

• Stacked on perf(gitx): search PATH for git once per PATH, not on every call #18, since it resolves the core binary once per PATH through perf(gitx): search PATH for git once per PATH, not on every call #18's cache. Merge perf(gitx): search PATH for git once per PATH, not on every call #18 first; this PR's base then moves to main.
• Where to look: coreGit in internal/gitx/gitx.go, and GIT_EXEC_PATH added to lookGit's key, since it changes what --exec-path prints.
• Behavior change, deliberate: jig runs <exec-path>/git instead of the first git on PATH. A wrapper named git that only starts git (Git for Windows' launchers, a scoop shim) is skipped. A wrapper that does more (say hub aliased as git) is skipped too, for jig's own calls. Everything git reads from config, the environment, and its own install is the same either way.
• Why --exec-path and not mingw64\bin: it is git's own answer to where its programs live, on every platform. git's Makefile always places git there (a link, symlink or copy), so no install-layout knowledge is needed. Git for Windows also ships the DLLs that git.exe needs in that directory.
• Cost: one extra git --exec-path process per distinct PATH, per process. A traced suite run starts 34 jig processes that call git at all (median 55 calls each), so this pays for itself on a process's second call.
• Safe to skim: the tests' assertSameFile helper and the DECISIONS.md entry.

Closing in favor of #23.

The pre-merge review found a real behavior change here, and I reproduced it. Git for Windows' git.exe only adds its mingw64\bin and usr\bin to the PATH of what it starts when MSYSTEM is unset, and it puts them behind %HOME%\bin; the cmd\git.exe launcher always adds them, ahead. With MSYSTEM=MINGW64 and Git's directories off PATH, a #!/bin/sh pre-commit hook runs through the launcher and fails with "cannot spawn .git/hooks/pre-commit" through git.exe. The same condition would hide the credential manager and git-lfs. jig drives users' repos, so it keeps running the first git on PATH.

#23 gets the CI benefit without touching the product: the Windows test leg puts git --exec-path first on PATH, where pwsh runs with MSYSTEM unset. Measured on the same runners, that is −23% on verifydeliver's publish tests (152 s → 117 s mean), more than this PR's −10%, because the nested git processes of a local push skip the launcher too.