darnit's git calls can run programs from the audited repository's config #617

S5 (proposed in #578) treats the audited repository as untrusted. Some git commands darnit runs on it execute programs named in that repository's .git/config:

• git status runs core.fsmonitor. darnit runs it in core/audit_cache.py:124 (every audit), server/tools/git_operations.py:610, and remediation/git_state.py:83,97.
• git log --format=%G? runs gpg.program / gpg.ssh.program (darnit_gittuf/handlers.py, GT-02.01).

The other calls (rev-parse, remote get-url, describe, symbolic-ref, tag --list, shortlog, show-ref) run nothing from config, because output is captured and so no pager runs.

The exposure is narrow. git clone never copies .git/config, so this needs a directory whose .git came from someone else: an archive, a shared volume, a prepared workspace. Running darnit natively on such a directory is already exposed today, and #586's safe.directory doesn't change that.

Proposed fix

Route every read-side git call through one helper. remediation/git_state.py:run_git exists already. The helper should pass -c core.fsmonitor=false, and for signature checks pin gpg.program and gpg.ssh.program to the auditor's defaults. Add a test with a planted core.fsmonitor that must not run during an audit.

Out of scope: remediation's git commit runs the repository's hooks (git_operations.py:294). That is the user's own checkout and their own hooks, which is expected.

Drafted with Claude Code; reviewed and posted by me.