feat(adapters): GitLab integration (Bitbucket optional)

**Context:** ROADMAP.md → Additional git providers

---

## Component

API or orchestration

## Describe the feature

**GitLab** (and optionally Bitbucket) as git providers: same workflow model, provider-specific API adapters for clone, PR/MR, webhooks, and reviews.

## Use case

Teams on GitLab cannot use ABCA without GitHub. Multi-provider support broadens adoption while keeping workflow YAML portable.

## Proposed solution

1. `GitProvider` adapter interface; GitHub implementation refactored as reference.
2. GitLab: MR creation, pipeline status webhooks, token/OAuth via Token Vault (#249).
3. Blueprint `git_provider: github | gitlab`.
4. CLI onboarding for GitLab repos.
5. Bitbucket as stretch goal / follow-up.

## Other information

- Identity pattern from **Per-repo GitHub credentials** (#50, #249) should generalize.
- Design context: `docs/design/ARCHITECTURE.md`, `docs/design/INPUT_GATEWAY.md`.

- [x] This might be a breaking change

Start with ROADMAP.md, docs/design/ARCHITECTURE.md, and docs/design/INPUT_GATEWAY.md, then review the existing GitHub implementation and related issues #50 and #249. Clarify the adapter and credential boundaries before implementation; done would require an agreed scope for GitLab provider support across merge requests, webhooks, reviews, blueprints, and CLI onboarding.

Written by the indexing model from the issue text.