test(project): the #1634 scratch repository's local clone can lose a loose object mid-copy #1906

tests/project/test_release_tags_the_run_sha_1634.py::TestTheCountsAreOfTheReleasedTiers::test_a_finished_release_reads_complete_after_the_tiers_grow failed on main 95caa8b36, in the Python 3.13 job (117882433027) of Unit Tests run 39196791944:

AssertionError: 128 != 0 : git clone -q /tmp/pcapkit-1634-zdk7eb87/origin.git /tmp/pcapkit-1634-zdk7eb87/work: fatal: failed to copy file to '/tmp/pcapkit-1634-zdk7eb87/work/.git/objects/98/d66370d9de7ad9ae6c5f9d5c95b8166b8443fe': No such file or directory

The rest of that job passed (4535 tests), and the PR that made 95caa8b36 (#1905) touches neither this test nor what it exercises. So the failure is intermittent. It is related to #1644, but that fix does not cover it: the class's setUp already sets maintenance.auto=false, gc.auto=0 and gc.autoDetach=false through GIT_CONFIG_*, yet the local clone in ScratchRepository.checkout still raced something in the scratch repository.

Fix: find what removes or moves the loose object while git clone copies it, for example a background process left by an earlier push, the hardlink-or-copy path of a local clone, or a setUp ordering gap. Then make the scratch repositories immune to it, for example with clone --no-local, or by applying the GIT_CONFIG_* before super().setUp() runs git init. Add a test that forces the interleaving, and check that it fails without the fix.