Add GitLab provider methods for Seer PR-iteration

[alexsohn1126]

Summary

We need GitLab implementations for three provider methods so that Seer's PR-context-gathering agent tools can work on GitLab. These tools let the Seer Explorer agent read context about a PR/MR (check runs, reviews, review comments) before iterating on it. They are currently GitHub-only, gated on the GitLab provider lacking these methods.

• Agent tools PR (consumer): getsentry/seer#6763
• ScmRepoClient methods PR (the wrappers calling these provider methods): getsentry/seer#6762

The GitHub provider already implements all three. The GitLab provider (src/scm/providers/gitlab/provider.py) does not.

Methods to add on the GitLab side

1. list_check_runs_for_ref — needed, cleanly feasible

Backs the agent's get_pr_failed_check_runs tool, which lists the latest check runs for a commit ref so the agent can see which CI checks failed on its PR.

GitLab equivalent: List the statuses of a commit — GET /projects/:id/repository/commits/:sha/statuses (https://docs.gitlab.com/api/commits/). It returns status, name, description, target_url, created_at, finished_at, allow_failure, etc., and an all param that maps to our timestamp_filter latest-vs-all. The GitLab provider already has check-run mapping for create_check_run/get_check_run, so that mapping can be reused.

2. list_pull_request_reviews — needed, but only an approximation is possible

Backs the agent's get_pr_reviews tool, which lists submitted reviews on a PR.

GitLab has no GitHub-style review objects — there's no review with a state (APPROVED/CHANGES_REQUESTED/COMMENTED) and a body. The closest is merge request approvals — GET /projects/:id/merge_requests/:iid/approvals (https://docs.gitlab.com/api/merge_request_approvals/), which only captures who approved and when. An implementation could map approvals to approved-only reviews, but "changes requested" / "commented" reviews cannot be represented. Flagging this as a semantic gap: full parity isn't achievable, and we should agree on whether an approvals-only approximation is acceptable here.

3. get_review_comments — needed, but not portable as-is

Backs the agent's get_pr_review_comments tool, which lists the inline diff comments belonging to a single review (review_id).

Since GitLab has no review objects, there is no review_id to key on, so the GitHub-shaped endpoint can't be ported directly. GitLab's inline diff comments live as notes inside discussions (already exposed via get_pull_request_review_threads). Options: (a) change the contract to "all MR diff comments" backed by discussions/notes, or (b) leave it unsupported on GitLab. Would like input on the preferred direction.

4. get/delete/list reactions in PR review comments

Needs more research, but PR review comments are different from just comments in GH but same endpoint shape is used for MR, notes, discussions in GitLab:

https://docs.gitlab.com/api/emoji_reactions/#add-reactions-to-comments

therefore minimal work required