Retry more real-network integration tests on gitlab.com 502s

What does this MR do?

Sets GET_SOURCES_ATTEMPTS=3 on six more tests' build fixtures (individually, or once at a shared common/buildtest helper where multiple executor packages' test variants go through the same code), giving their real-network git clone/fetch a retry instead of none.

Why was this MR needed?

While reviewing recent pipeline failures across several open MRs, found the exact same root cause as #39626 (closed) (fixed for TestBuildCacheHelper in !6997 (merged)) recurring in six more tests: a transient HTTP 502 from gitlab.com's own git host during clone/fetch, with no retry budget (DefaultGetSourcesAttempts = 1). See #39629 (closed) for the full list of affected tests and job links.

Two of the six (TestBuildExpandedFileVariable, TestBuildMasking) are fixed once at their shared common/buildtest helper (RunBuildWithExpandedFileVariable, testBuildWithMasking) rather than per test file, since every executor package's variant of those two tests shares the same underlying code. This also happens to cover TestBuildMasking's docker/autoscaler variant, previously seen failing on an unrelated Docker Hub pull reset (#39627 (closed)) - same missing retry budget, different transient trigger.

Used 3 rather than 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.

What's the best way to test this MR?

go build -tags integration ./... passes. golangci-lint run --build-tags integration on all five touched packages shows no new issues (all pre-existing findings are on unrelated, unmoved lines). A real HTTP 502 isn't practical to force locally - verification is these tests' flake rate over subsequent CI runs.

What are the relevant issue numbers?

Closes #39629 (closed)