Disable automatic Git maintenance in cloner

[winor30]

What

This disables Git's automatic maintenance while the git cloner is preparing a temporary checkout for CloneToBucket.

The cloner now passes these config overrides to the Git commands that operate on the temporary clone:

-c maintenance.auto=false
-c maintenance.autoDetach=false
-c gc.auto=0
-c gc.autoDetach=false
-c fetch.writeCommitGraph=false

The regression test checks the actual Git argv via GIT_TRACE2_EVENT, so it pins down that these options are passed before fetch, checkout, and submodule.

Why

I ran into this through bufbuild/buf-breaking-action@v1 on GitHub Actions. The action failed while cloning the against input with missing files under .git:

Failure: could not clone https://github.com/winor30/buf-breaking-repro.git: stat .git/objects/bitmap-ref-tips_4VcgMk: file does not exist                                                                                                                                                                                      stat .git/info/refs_9E0SyG: file does not exist

That run was on ubuntu-24.04 with Git 2.54.0.

The cloner creates a temporary Git repository, runs fetch/checkout/optional submodule commands, and then copies the result into a storage bucket. In the affected path, .git files can be part of that copy. If Git kicks off automatic maintenance or GC around the same time, it can create and remove temporary files under .git while storage.Copy is walking the directory. That leaves storage.Copy with a path it saw during the walk, but can no longer stat/open.
I verified the race with a local reproducer that puts a small git wrapper at the front of PATH. The wrapper delegates to the real Git binary, but after git fetch it simulates background Git maintenance by creating files under .git/buf-copy-race and deleting them while CloneToBucket is copying the checkout.

On main, cloning with no matcher fails in the same way:

CloneToBucket error: stat .git/buf-copy-race/file-0: file does not exist

On this branch, the same reproducer passes because the maintenance-simulating path is not started.

[CLAassistant]

All committers have signed the CLA.

[doriable]

This makes sense and looks good to me! Thank you for this contribution.