CI: Authenticate gitlab.com clones via GIT_CONFIG_GLOBAL file

What does this MR do?

Makes authenticated gitlab.com clones of gitlab-org/gitlab actually work, so they use the higher authenticated Gitaly rate limit instead of failing with GitLab is currently unable to handle this request due to load.

Why the previous attempts failed. The GIT_CONFIG_* variables added in 233dcc0121d6 never authenticated, for three compounding reasons:

1. the proactiveAuth key was quoted (http."https://gitlab.com".proactiveAuth), which never matches the request URL;
2. the builder image shipped git 2.39.5, which predates proactiveAuth (added in git 2.46); and
3. GitLab expands ${CI_JOB_TOKEN} when resolving the variables: block — before the job token exists — so the credential helper baked in an empty password (confirmed via a debug job: token present and api HTTP 200, but the helper returned password: 0 chars).

!9501's URL-embedding workaround didn't help either: git never sends URL-embedded credentials preemptively (it waits for a 401, which gitlab.com never issues for a public repo).

This MR (adapts the approach from !9488):

1. Writes the auth config to a file (GIT_CONFIG_GLOBAL=/tmp/.gitconfig) in before_script, where the job token exists. A quoted heredoc keeps ${CI_JOB_TOKEN} literal so the credential helper's shell expands it at clone time — the token never lands on disk. GIT_CONFIG_GLOBAL is read by every git invocation, including those omnibus spawns.
2. Path-scopes proactiveAuth to gitlab-org/gitlab — the only project the omnibus-gitlab CI job token is allowlisted for — so other gitlab.com mirrors keep cloning anonymously. The builder image now ships git 2.47.3, which supports proactiveAuth.
3. Reverts !9501 (the URL-embedding in Gitlab::Version#remote).

Related issues

Related to #9776. Supersedes !9488.