Start auto-remediation runs only from default branch pipelines

What does this MR do and why?

Starts auto-remediation scheduler runs only from default branch pipelines that are not registry image scans.

• With vulnerabilities on any branch, feature branch pipelines ingest SBOMs too and publish the same ingestion event, so each one starts a scheduler run. Every remediation request targets the default branch, and the docs already require results on the default branch.
• Registry image scans run on the default branch and report container contents, which have no manifest in the repository.
• A new Eligibility.trigger_pipeline? holds the rule next to the other eligibility rules, and SchedulerWorker#handle_event skips any other pipeline.

Under the scheduler rate limit from !267539 (merged), this also stops feature branch and registry scan runs from using a project's five-minute window.

There is no feature flag. A skipped feature branch run scans the same project-wide occurrences that the next default branch run scans, so no remediation work is lost.

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/636846
• Rate limit MR: !267539 (merged)
• Container scanning occurrences picked up by the scheduler: https://gitlab.com/gitlab-org/gitlab/-/work_items/638009

Screenshots or screen recordings

Not applicable, no UI changes.

How to set up and validate locally

1. Pick a project with a dependency scanning auto-remediation profile attached.
2. Run a pipeline with dependency scanning on a feature branch. After SBOM ingestion, log/application_json.log has no DependencyManagement: started an auto-remediation workload line for it.
3. Run the same pipeline on the default branch. With a remediable vulnerability, a DependencyManagement: started an auto-remediation workload line appears as before.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.