Retry TestBuildCacheHelper's git fetch on transient reset

What does this MR do?

Sets GET_SOURCES_ATTEMPTS=3 on TestBuildCacheHelper's build fixture, giving its git fetch one retry instead of none.

Why was this MR needed?

TestBuildCacheHelper uses common.GetRemoteSuccessfulBuild(), which clones from a real remote repo over the network - see https://gitlab.com/gitlab-org/gitlab-runner/-/jobs/15433879299, where TestBuildCacheHelper/pwsh/no_cache_settings_provided,_no_job_cache_provided failed on error: RPC failed; curl 56 Recv failure: Connection reset by peer during the fetch itself.

The production default (DefaultGetSourcesAttempts = 1 in common/consts.go) gives no retry budget, so a single transient network reset fails the whole test outright with no chance to recover. This file already has an established pattern for setting this exact variable on a build fixture (see the GIT_SUBMODULE_STRATEGY test a few hundred lines up, for a different reason). Used 3 here rather than that test's 2 to match defaultPullMaxAttempts in the image-pull retry manager - the existing convention elsewhere in this codebase for retrying a transient external-dependency failure.

No production behavior changes: DefaultGetSourcesAttempts is untouched, so real runner deployments are unaffected. This only raises the retry budget for this one test's own build.

What's the best way to test this MR?

go build -tags integration ./executors/shell/... and golangci-lint run --build-tags integration ./executors/shell/... both pass with no new issues. A true reproduction of the underlying network reset isn't practical to force locally or in a unit test - verification is watching this test's flake rate over subsequent real CI runs.

What are the relevant issue numbers?

Closes #39626 (closed)