[sairus2k]

Problem

After the last merge, Runner.waitForMainPipeline polls ListPipelines(ref, sha) and reads pipelines[0] (newest by ID). When the target branch has a pipeline schedule, the scheduled pipeline runs on the same HEAD SHA, gets a higher ID and usually finishes much faster. The train then reported Main pipeline success from the scheduled pipeline, while the TUI still linked the merge pipeline, which was still running (in one case it had not even started).

Fix

APIClient.ListPipelines now filters by source=push, so only the pipeline created by the merge counts. This also covers the race where a scheduled pipeline is created before the push pipeline, and it excludes web/api/trigger pipelines on the same SHA. The method has a single production caller, so the interface signature, mocks, runner and TUI are unchanged.

Behaviour change

If the target branch never gets a push pipeline (e.g. workflow:rules skip push), the train now waits until main_pipeline_timeout_m and logs an error instead of reporting another pipeline's status.

Testing

• New TestListPipelines_OnlyPushPipelines: the httptest server returns a newer scheduled pipeline unless source=push is set. It fails without the fix and passes with it.
• go build, golangci-lint run ./..., go test ./..., govulncheck ./... all pass.
• Verified against a GitLab 19.5 instance: source=push returns exactly the merge pipeline for the affected SHAs.

Not in this PR

• skipped/manual are not terminal statuses in waitForMainPipeline, so such a merge pipeline waits for the timeout.
• The unused status parameter of ListPipelines.