fix(gitlab): use metadata endpoint for server information - #1374

Summary

• use GitLab's /metadata endpoint when initializing the API client
• use the same endpoint when acceptance tests detect the GitLab edition
• add a regression test for the initialization request sequence

Root cause

GitLabForm still queried the legacy-compatible /version route even though
the project is moving its minimum supported GitLab version forward and the
maintainer explicitly identified /metadata as the preferred endpoint in
#1203.

Changes

The server information request now uses /metadata. The returned fields used
by GitLabForm (version, revision, and enterprise) and all subsequent
initialization behavior remain unchanged.

The acceptance-test edition fixture now uses the same endpoint, avoiding a
difference between production and test setup.

Validation

• .venv/bin/python -m pytest -q tests/unit/gitlab/test_core.py — 8 passed
• .venv/bin/python -m pytest -q tests/unit — 239 passed
• .venv/bin/python -m pytest -q --collect-only tests/acceptance/standard/test_running.py — 4 tests collected
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv run --no-sync qa lint — passed
• UV_CACHE_DIR=/private/tmp/gitlabform-uv-cache uv lock --check — passed
• git diff --check origin/main...HEAD — passed

The full acceptance suite requires a disposable GitLab instance and was not
executed locally. A repository-wide collection attempt also encounters the
existing duplicate test_group_settings.py module names across the Premium
and Ultimate suites, so collection was verified with a representative
standard suite instead.

Compatibility and risk

No configuration or migration is required. GitLab documents /metadata as
available since GitLab 15.2, while GitLabForm currently warns for versions
earlier than 16. The response fields consumed by GitLabForm are unchanged.

This implements the /metadata migration subtask discussed in #1203.