Fixes #2313.

Problem

Local clones spawn the service program, like git-upload-pack, by name, and fail with NotFound when it isn't in PATH — even though git itself is findable. As Eliah Kagan (@EliahKagan)'s analysis in the issue lays out, this is common on Windows, where installations like scoop's put git in PATH but not its subcommands, and where we already support git not being in PATH at all.

Changes

Following the resolution order discussed in the issue:

1. Unchanged first attempt: spawn the service program by name, using PATH as before.
2. On NotFound, find it where git finds it: the new gix_path::env::core_dir_program(name) looks the program up in the directory reported by git --exec-path (via the cached core_dir()), which is the location git itself uses to run its subcommands — and run it from there by absolute path. This works on all platforms and is the "conscious choice" variant: it's very clear which program runs.
3. Otherwise, let git run it: spawn exe_invocation() with the service as its subcommand — passed as a separate argument, no shell involved.

The fallback can only ever engage for local repositories: it is gated on the non-SSH arm of the transport, so remote invocations keep the standard git-upload-pack command name that servers may customize. The async client has no file transport, so nothing changes there. As the retry is keyed on the failed spawn itself, there is no TOCTOU between checking and running. git-receive-pack gets the same treatment as the logic is service-generic.

The auxiliary.rs machinery for Git-for-Windows directories is deliberately left untouched — --exec-path already answers this particular question on every platform, while the broader executable-finding facility discussed in the issue (and #1886) remains open for its own design.

Validation

Reproduced the issue and verified the fix end-to-end on macOS with a PATH containing only a git symlink:

• before: gix clone file://… fails with No such file or directory (os error 2)
• after: the clone fully succeeds via the exec-path program
• with GIT_EXEC_PATH additionally pointing at an empty directory, the clone still succeeds via the git upload-pack form, exercising the last fallback.

Tests:

• gix-path: core_dir_program returns an existing absolute path for git-upload-pack and None for programs that don't exist.
• gix-transport: the fallback invocation shape is asserted for both branches — never a shell, repository path as final argument, sub-command as a separate argument in the git-run form.
• cargo test -p gix-path -p gix-transport --features blocking-client -p gix -p gitoxide-core, cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --all -- --check all pass.