ci: pass the integration test token as GITLAB_TOKEN_TEST

What does this MR do?

The tests:integration job has run no integration test since the 3.0 release. SetupIntegrationClient reads its token from GITLAB_TOKEN_TEST, the name it took in b423cc67, which reached main with !3026 (merged), while the job still exports it as GITLAB_TOKEN only, the name make testacc-up and the compose file seed the instance with. So every test in gitlab_test/ skips with GITLAB_TOKEN_TEST environment variable not set, and the job passes:

main pipeline	tests:integration
2026-09-07, scheduled	132 tests
every one since 2026-09-08, scheduled or on a merge; the latest on 2026-09-29	70 tests, 70 skipped

The job now also passes the token it seeds the instance with under the name the tests read, GITLAB_TOKEN_TEST: "$GITLAB_TOKEN", so the two cannot drift apart again. I found it while adding integration tests in !3066, which the job would otherwise not run either. Like !3066, this comes from maintaining gitlab-mcp-server, an MCP server built on this library, whose upstream-bugs.md records the finding under entry 19.

What I left alone

• make test-integration, which docs/guides/AddingAPISupport.md names as the way to run the tests locally, passes neither variable, so a local run skips everything too unless GITLAB_TOKEN_TEST is exported by hand. I read the rename as possibly deliberate, keeping a developer's own GITLAB_TOKEN out of a suite that creates and deletes users, so I did not change the target; I am happy to add GITLAB_TOKEN_TEST=$(GITLAB_TOKEN) to it here if you want both fixed.

Is this a breaking change?

No. It adds one job variable and changes no code.

How was this tested?

The job's rule is $ENABLE_EE_ACCEPTANCE_TESTS == "true", which the pipelines on main meet, those of each merge as well as the scheduled ones (job 16789059596 ran on the merge of !3048 (merged)), and a merge request pipeline does not, so this merge request's own pipeline cannot show the change: it shows in the first main pipeline after it merges, as the number of tests the job reports. The variable expansion is the one the job already relies on for DOCKER_CERT_PATH.

What I do not know is whether the suite passes. It has not run in CI since 2026-09-07, through every release from 3.0.0 to 3.15.0, and I have not run the whole of it against an instance set up the way the job sets one up (the license file, the SAML provider and the registry of scripts/gitlab.rb). Its first run after this merges may fail on something that landed in between.

Related to !3066