Hermes puts its provisioned tools on PATH but never passed their tool
env, so the bundled git ran without GIT_EXEC_PATH. A relocated
dugite-native build resolves helpers, templates and system config
against a prefix that existed on the BUILD machine, so every agent-run
`git clone`/`fetch`/`push` over http failed on a managed install:
git: 'remote-http' is not a git command.
`git --version` kept working, which is why this went unnoticed — nothing
that skips a helper is affected.
managed_tool_env() already computed the right values; two call sites
simply did not use it. tools/environments/local.py applied
managed_path_dirs() alone, and noninteractive_git_env() — the shared
helper behind MCP installs, plugin updates, worktree fetches and the
desktop review pane — only added its prompt-suppression vars to a copy
of os.environ. Both now layer the tool env in under any caller value, so
a user pointing at their own git tooling still wins, and both fail open
so a system git keeps working untouched.
Also adds PREFIX, which dugite's own setupEnvironment() sets on Linux
and we were missing. Dugite's source is explicit about why: "when
building Git for Linux and then running it from an arbitrary location,
you should set PREFIX for the process to ensure that it knows how to
resolve things." The env is the vendor's supported interface for a
relocated git, not a workaround.
Tests drive a real provisioned git and assert on the clone: PATH alone
reproduces the helper failure, PATH plus the tool env reaches the
network instead.
