CI: Only set gitlab.com credential helper on gitlab.com

What does this MR do?

CI: Only set the gitlab.com credential helper on gitlab.com.

!9510 (merged) unconditionally wrote a GIT_CONFIG_GLOBAL in before_script that set proactiveAuth = basic plus a CI_JOB_TOKEN credential helper for https://gitlab.com. On dev.gitlab.org, CI_JOB_TOKEN is issued by (and only valid on) dev.gitlab.org, so forcing it onto gitlab.com made git ls-remote of the public gitlab-org/gitlab repo fail with HTTP Basic: Access denied.

This broke the manifest:upload job, which resolves component versions against the public gitlab.com sources (it forces ALTERNATIVE_SOURCES=true) even on dev.gitlab.org. Example failure: https://dev.gitlab.org/gitlab/omnibus-gitlab/-/jobs/38081263

This MR guards the credential helper and proactiveAuth behind CI_SERVER_HOST == gitlab.com. The [user] identity is still written on every server (it is a fallback for omnibus' git cache), but dev.gitlab.org and other mirrors go back to cloning gitlab.com anonymously as they did before !9510 (merged).

Note: this restores the pre-!9510 behavior where dev.gitlab.org pipelines use the lower unauthenticated Gitaly rate limit for gitlab.com clones. If that becomes a problem, a follow-up could provide a token valid against gitlab.com or point those clones at a dev.gitlab.org mirror.

Related issues

Follow-up to !9510 (merged).

Checklist

See Definition of done.

Required

• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• Latest Merge Result pipeline is green.
• When ready for review, MR is labeled workflowready for review per the Distribution MR workflow.
• The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable.

For GitLab team members

• If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.