fix(gitlab): always re-collect MR commits regardless of MR updated_at…

[bujjibabukatta]

When running incremental collection, GetMergeRequestsIterator filters merge requests using gitlabupdatedat > since.
When running incremental collection, GetMergeRequestsIterator filters merge requests using gitlab_updated_at > since. This works fine for notes and reviews — if the MR hasn't been touched, nothing new to collect. But for commits it's the wrong filter. Pushing new commits to a MR's source branch doesn't update gitlab_updated_at on the MR itself, so those MRs get skipped entirely and their new commits are never fetched. This is exactly why full refresh works but normal collect misses data.
The fix is to pass nil instead of apiCollector when calling GetMergeRequestsIterator in the commit collector. Passing nil skips the time filter so every MR is scanned for commits on each run, matching full refresh behaviour. The MR commits endpoint is lightweight so the performance impact is minimal. Notes and reviews collectors are unchanged — they still pass apiCollector and keep their incremental filtering, which is correct for those entities.

[bujjibabukatta]

Hi @klesh could you please review and approve pull request?

[klesh]

Please fix the failed checks first.

[bujjibabukatta]

Hi @klesh — I've fixed the build. 5c66376 corrects the if-brace syntax error in GetMergeRequestsIterator that was breaking lint, unit-test, and the e2e checks; it now compiles cleanly (go build ./plugins/gitlab/... passes locally) and I've merged latest main. The workflows are showing "awaiting approval" — could you approve the run so CI can execute, then re-review? Thanks!

[klesh]

LGTM.
Thanks for your contribution.