Isolate the tests from the developer's git config

Tests across walgit-bundle, walgit-cli, walgit-git and walgit-wal spawn
`git init` / `git commit` in temp repos without sandboxing git config,
so they inherit the developer's. A contributor with commit.gpgsign set
gets

    gpg failed to sign the data: No secret key
    fatal: failed to write commit object

on roughly thirty tests — green on a bare CI runner, red on a signing
laptop. That is the worse way round: CI cannot see it, so the suite rots
for exactly the contributors who sign their work.

GIT_CONFIG_GLOBAL does not disable a setting, it replaces the path git
reads global config from. Pointed at /dev/null, ~/.gitconfig is never
opened and its include.path chain is never followed, which is where a
signing flag often hides several files deep. Nulling the config also
drops user.name and user.email, hence the fixed identity.
tests/lib-auth.sh already does this for the shell suite.

Scope is deliberately wider than tests. cargo's [env] covers every
process cargo launches, so `cargo run -p walgit-server` also gets a
neutered global config. That is wanted — a server spawning index-pack
and repack should not inherit a laptop's hooks, aliases, gc.auto or
fsmonitor — but it is not "tests only", and it is Unix-only (/dev/null).
The scoped alternative is .env() on each git-spawning helper across four
crates: no blast radius, ~40 lines of duplication, and every new test
that spawns git has to remember. One place won.

`force` stays at its default, so a value already exported still wins.