Add proper GitLab support

Clear and concise description of the problem

Add proper GitLab support

Suggested solution

Add proper GitLab support

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Status check — still blocked on #1390, and that blocker is now well-defined.

GitProviderName remains a single-member union ('github') on purpose, and src/git/github-provider.ts is still the only implementation. What has changed is that the surface a second provider must satisfy grew substantially this cycle — reviews, check runs, reactions, collaborator permissions, workflow-run logs, file reads at a ref, GraphQL auto-merge and issue pinning.

That makes #1390 more valuable rather than less: it should extract the interface from the actual call sites and ship a conformance test suite, so implementing this issue becomes "make the mock pass" rather than archaeology across a 1,700-line file. Worth doing #1390 first.

Unblocked. #1390 landed the GitProvider abstraction.

Implementing this is now a checklist rather than archaeology:

1. Write src/git/gitlab-provider.ts implementing GitProvider (src/git/provider.ts). Required members are what every platform has; optional ones are gated by ProviderCapabilities — declare only what you actually implement.
2. Make runProviderConformance('gitlab', () => new GitLabProvider(...)) pass. test/git/provider-conformance.ts tests contracts, never URL shapes or status codes, so it runs against a live client with fixtures or a fake. test/git/in-memory-provider.ts is a complete reference implementation to read alongside it.
3. Add 'gitlab' to IMPLEMENTED_PROVIDERS and the factory branch in createProvider().
4. Add GitLab CI templates to src/setup.ts.

Token resolution is already conventional (CI_JOB_TOKEN, GITLAB_TOKEN, BUDDY_BOT_TOKEN), and repository.provider: 'gitlab' currently type-checks but is rejected at validation with a link here.

Terminology note: a merge request is a PullRequest at the interface boundary — translate at the provider edge rather than threading two vocabularies through the codebase. See docs/advanced/providers.md.

Implemented in acdd885 and 2a6872d.

GitLabProvider passes the conformance suite from #1390, run against a fake API that speaks GitLab v4 — so the tests exercise the real class and its actual HTTP mapping rather than a stub. That immediately caught a bug a stub would have hidden: a DELETE returns 204 with an empty body, and parsing it as JSON made every successful branch deletion throw.

Translation details, each of which would otherwise be a silent bug:

• iid is the number in the URL; the global id addresses the wrong merge request on every project but the first
• a group path's slashes are part of the project name, so the whole path is encoded as one segment
• a draft is marked by a title prefix, stripped on read so an update round-trip does not grow Draft: Draft:
• each commit action must say create or update, and GitLab rejects the whole commit if one is wrong — so existence is resolved against the base rather than trusted from the caller's type

Capabilities declared honestly: no issue pinning, no team reviewers. Everything else maps — commit statuses for check runs, merge-when-pipeline-succeeds for auto-merge, award emoji for reactions, job traces for CI logs.

.gitlab-ci.yml generation included. GitLab schedules live in the project UI, so the jobs gate on a BUDDY_JOB variable and the file carries instructions for creating them — a file assuming a schedule: block would never run and give no clue why. It also says plainly that CI_JOB_TOKEN cannot open merge requests, which is the failure a first scheduled run would otherwise hit.

buddy-bot setup now detects GitLab from the remote, subgroup paths included.