Add GitLab issue → MR automation (ticket→PR parity with Jira)

[smolpaws]

Summary

Add a GitLab issue → merge request automation to automations/catalog/, mirroring the existing jira-issue-to-pr.

Motivation

"Ticket → PR" is a top-requested agentic use case (raised in #proj-agent-canvas by Joe Pelletier: make it first-class for Jira, Linear, and the big-3 git providers). Today the automations catalog covers:

• jira-issue-to-pr — Jira issue → GitHub PR ✅
• linear-triage-assistant — triage only (not issue → PR)
• github-pr-reviewer, github-repo-monitor — GitHub, review/monitor
• GitLab: nothing ❌
• Bitbucket: nothing (provider skills only)

GitLab is one of the big-3 git providers and has no ticket→PR automation.

Proposal

New automation automations/catalog/gitlab-issue-to-mr/ with a manifest.json following the same shape as jira-issue-to-pr:

• Trigger: watch a GitLab project for issues carrying a configurable label.
• Action: open a GitLab merge request per new labeled issue; read the target repo/branch from the ticket body (same "no repo param" convention as the Jira one).
• requires.integrations: gitlab (read issues, open MRs).
• Provider building blocks already exist as skills; this wires them into a scheduled automation.

Acceptance criteria

• manifest.json validates against automations/catalog.schema.json.
• npm run build:automations regenerates automations/index.js including the new entry.
• Entry carries a valid requires.integrations block (so it renders in the canvas "recommended automations" tab).

Filed on behalf of the #proj-agent-canvas thread discussion (Neubig, Joe Pelletier). 🐾

[smolpaws]

Duplicate — GitLab ticket→MR is already tracked by #437 (Jira → GitLab) and #439 (Linear → GitLab), part of the #437–#441 source×target matrix. Closing in favor of those. 🐾