chore(deps): gitlab.com/gitlab-org/api/client-go from 0.127.0 to 1.46.0

[mbevc1]

Replaces #686

[claude]

Claude finished @mbevc1's task in 4m 4s —— View job

---

PR Review: Bump gitlab.com/gitlab-org/api/client-go from 0.127.0 to 1.46.0

• Phase 1: Static analysis (go build, go vet, go mod tidy)
• Phase 2: Code review
• Phase 3: Summary

Static Analysis

All three checks pass cleanly:

• go build ./... — compiles successfully
• go vet ./... — no issues
• go mod tidy && git diff --exit-code go.mod go.sum — dependencies are tidy

Code Review

Changes overview (3 commits):

1. go.mod/go.sum: Bumps gitlab.com/gitlab-org/api/client-go from v0.127.0 to v1.46.0 (major version bump). Several transitive dependencies are also updated (go-retryablehttp, antlr4, danieljoos/wincred, godbus/dbus, cel-go, go-querystring, golang.org/x/exp), and one removed (stoewer/go-strcase).

2. internal/gitlab/gitlab.go: GetMergeRequestApprovers signature changes mrIID and version from int to int64. This is required because the upstream BasicMergeRequest.IID field changed to int64 in the new library version.

3. internal/gitlab/gitlab_test.go: Test struct field mrIID updated from int to int64 to match the new signature.

Analysis:

• The int → int64 type change for mrIID is necessary and correctly propagated. The two call sites (newPRGitlabEvidenceV1 at line 81 and newPRGitlabEvidenceV2 at line 103) pass mr.IID directly from the upstream struct, so the types align.
• The version parameter also changed to int64 — this is a side effect of sharing the signature. It's only ever called with literal 1 or 2, so the widening is harmless.
• Test values (mrIID: 2, mrIID: 1) are untyped integer literals, so they work with int64 without any cast.
• No other files in the repo reference GetMergeRequestApprovers or use the mrIID type directly, so the change is complete.

Good Work

• Clean, minimal change — only touches what's necessary for the major version bump.
• Tests are updated in lockstep with the production code.
• The breaking change (int → int64) is handled correctly across all call sites.

Verdict: LGTM — this is a straightforward dependency bump with a well-handled breaking API change. No issues found.