Merge-queue deploy can start before the cosign matcher-efficacy check passes #4148

🤖 Generated by the Agentic Engineer

Evidence

On main, ci.yaml's ci-required-checks gate lists validate-matcher-efficacy, but deploy-prod.needs does not. That job runs on merge_group (it is the one validator that reads GHCR to check that the cosign matcher accepts a real signer, and it verifies proposed first-party Crossplane packages). Nothing orders it before the deploy.

So in the merge queue the two run in parallel: prod can be deployed with a revision whose matcher or package verification is failing. The PR is then evicted by the required-checks gate, and prod carries unmerged content that the gate rejected, until the heal restores it.

validate and naming are also missing from deploy-prod.needs, but both run on pull_request only, so they have no merge-group result to wait on.

Who this affects, and impact

Production. A merge group that fails matcher efficacy still reaches the cluster, which is the exact case #3005 was about (a matcher that verifies nothing halted GitOps delivery for ~5.5 hours). It also costs a heal cycle and a prod deploy per occurrence.

Expected behaviour

The merge-queue deploy does not start until every merge-group validator that ci-required-checks enforces has passed.

Acceptance criteria

• deploy-prod.needs includes validate-matcher-efficacy.
• An executable check fails when a merge-group validator required by ci-required-checks is missing from deploy-prod.needs, and is proven by a negative control.
• Pull-request-only validators are excluded by reading their if: guard, not by a hand-kept list.

Rough size: S. Part of #3091.