[codex] Ignore fsmonitor config in Git metadata reads

[bookholt-oai]

Summary

• keep Git metadata/status subprocesses independent of repository core.fsmonitor configuration
• preserve existing working-tree state reporting while making the helper behavior more predictable
• add regression coverage for get_has_changes when a repository defines an fsmonitor command

Validation

• cargo fmt --all
• cargo test -p codex-core test_get_has_changes_
• cargo test -p codex-git-utils

[evawong-oai]

Validated PR 22652 at head 37f8213.

Result: approve.

Validation performed:

1. Checked out the PR head and verified the worktree HEAD matched 37f8213 before running the test.
2. Added a targeted regression that exercises the changed metadata path through get_has_changes.
3. The test creates a temporary Git repository, writes a repository configured core.fsmonitor helper, and configures Git to use that helper.
4. The helper payload writes a marker file if Git invokes it. That marker is the signal for the reported behavior.
5. The test then writes an untracked file and calls get_has_changes, which runs the Codex Git metadata path that now invokes git with core.fsmonitor disabled.

Observed result:

1. get_has_changes returned Some(true), so Codex still detected the working tree change.
2. helper_ran was false, so the repository controlled core.fsmonitor helper did not execute.
3. The targeted test passed with 1 passed and 0 failed.

Relevant validation output:

ZDI_31270_AFTER_PR_FSMONITOR_VALIDATION has_changes=Some(true) helper_ran=false
test git_info_tests::zdi_31270_fsmonitor_after_pr_get_has_changes ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1743 filtered out; finished in 0.23s

Security conclusion: this validates the specific reported fsmonitor execution path after the PR. The metadata read still works, but a repository supplied core.fsmonitor helper is not executed during get_has_changes on the patched head.