test: the git-maintenance guard can read green from an ambient system gitconfig

[pbean]

test_template_leaves_no_detached_git_maintenance_writing_into_the_copies
(tests/test_conftest.py) grades behavior rather than the config key: it commits
into a real copy under GIT_TRACE2_EVENT and asserts no child_start event names
a maintenance or gc child. Its ablation — deleting
tests/conftest.py:458 — reddens that row alone, verified.

The channel

_isolate_ambient_git_ignores (tests/conftest.py:366) deliberately leaves
GIT_CONFIG_NOSYSTEM unset, documented at :382. So the probe subprocess still
reads the host's system gitconfig. On a host whose system config already sets
maintenance.auto=false or gc.auto=0, the spawn is suppressed for a reason that
has nothing to do with the fixture, and the row stays green even with the fixture
line deleted — the ablation would not redden there.

This does not affect CI (neither the ubuntu-24.04 nor the windows-2025 runner
image ships such a system config) and it does not weaken the fix itself, only the
guard's ability to prove the fix is what is doing the work on an arbitrary
contributor's box.

Options

• Set GIT_CONFIG_NOSYSTEM=1 on that one probe subprocess.run env, scoping the
  hardening to the assertion that needs it rather than to the whole suite. The
  existing env dict already passes {**os.environ, "GIT_TRACE2_EVENT": ...}, so
  this is one key.
• Or record the channel in the docstring so a contributor who ablates and sees
  green knows to check their system config first.

The narrow env-var scoping is preferred over touching
_isolate_ambient_git_ignores, whose choice not to set GIT_CONFIG_NOSYSTEM
globally is deliberate and load-bearing for other rows.

[coderabbitai]

🔗 Related PRs

#544 - fix: route the last two bare git spawns through the chokepoint, add the guard [merged]
#622 - fix(engine): stop refusing an isolated merge over unrelated untracked files (#460) [merged]
#633 - Guard path resolution across worktree, recovery, and TUI [merged]
#663 - test: de-flake the two open TUI flakes (#360, #581) and the template-copy race [open]
#644 - Expose verification command results to post-dev plugins [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[pbean]

Narrowed by `22a57a35` on PR #663, which adds `GIT_CONFIG_COUNT=0` to the probe subprocess env.

That closes the command-scope vector, which turned out to be the sharper of the two — measured on git 2.55.0 against a repo already carrying maintenance.auto=false, an ambient GIT_CONFIG_COUNT=1 / GIT_CONFIG_KEY_0=maintenance.auto / GIT_CONFIG_VALUE_0=true re-arms the spawn straight through the local config, because command-scope pairs outrank .git/config the way git -c does. GIT_CONFIG_COUNT=0 drops the inherited set entirely.

This issue stays open for the system-gitconfig vector, which is untouched: _isolate_ambient_git_ignores still leaves GIT_CONFIG_NOSYSTEM unset by design, so a host whose system config sets maintenance.auto=false or gc.auto=0 can still hold the row green with the fixture line ablated.

Note for whoever picks this up: setting GIT_CONFIG_NOSYSTEM=1 is not symmetric with the GIT_CONFIG_COUNT=0 fix. The fixture docstring records that suppressing system config removes Git-for-Windows' core.autocrlf and makes unrelated tracked files read as modified, and the CI matrix runs two Windows legs. It would also want applying to the git add -A call above the commit, not just the commit, so the staging and the commit see the same config. That is why it was left out of the narrower fix rather than folded in.