fix(ci): do-not-merge is not enforced on merge_group runs

[kyle-sexton]

Problem

After #5935, ci.yml runs on merge_group. There pr-contract reports skipped because the event carries no PR, so a do-not-merge label added after a PR enters the merge queue does not eject it. This becomes live once the github-iac merge-queue ruleset (melodic-software/github-iac#583) is applied.

Evidence

• .github/workflows/ci.yml:53 (merge_group trigger); ci-status reads the label only from the PR event.

Suggested fix

Pick one:

1. Document that the operator removes the PR from the queue after applying do-not-merge.
2. Parse the PR number from merge_group.head_ref (gh-readonly-queue/<base>/pr-<N>-<sha>) and check its labels. The format is documented only by prefix, and this covers only the newest PR in a group.

Found while working on #5935.

[kyle-sexton]

This was generated by AI during triage.

Routing: human-gated, needs decision (work-class: structural, bug, priority: high). Merge-safety surface.

The premise is now live. The body says this "becomes live once the github-iac merge-queue ruleset is applied". It has been: melodic-software/github-iac#583 merged 2026-10-03, and the main branch rules now include merge_queue. Basis: gh api repos/melodic-software/claude-code-plugins/rules/branches/main returned [..., "required_status_checks", ..., "merge_queue"]; gh pr view 583 -R melodic-software/github-iac shows MERGED 2026-10-03T04:20:39Z.

Bug confirmed against current code. On merge_group, pr-contract finds no pull request number and reports skipped; the workflow comment says so explicitly, reasoning that the label was already checked before the PR entered the queue. So a do-not-merge label applied after enqueue does not fail ci-status, and the PR merges. Basis: .github/workflows/ci.yml:52-63, and the pr-contract step pinned to melodic-software/ci-workflows at ci.yml:2387.

Why a human decision: the label is the hold AGENTS.md says ci-status enforces, and unattended lanes rely on it. Each fix option changes that contract, and option 2 likely lives in the SHA-pinned ci-workflows pr-contract composite, which is cross-repo.

Open question: how should a hold work once a PR is in the merge queue?

1. Document that the operator removes the PR from the queue after applying do-not-merge. Cheapest; relies on a human remembering; does nothing for a lane that labels a PR.
2. In pr-contract, parse PR numbers from merge_group.head_ref (gh-readonly-queue/<base>/pr-<N>-<sha>) and fail on a do-not-merge label. The ref format is documented only by prefix, and it names only the newest PR in a group, so earlier PRs in the same group are not covered.
3. (judgment, not verified against GitHub docs this session) On a labeled event adding do-not-merge, remove the PR from the queue through the API. Needs a write-scoped token on a label-triggered event.

Evidence that would settle it: whether GitHub's merge-group payload or API exposes every PR in a group (which would fix option 2's coverage gap), and whether lanes ever apply the label after enqueue.

Agent Brief

Type: Bug
Summary: A do-not-merge label applied after a pull request enters the merge queue must stop that pull request from merging.

Current behavior:
On merge-group runs, the pull-request contract step reports skipped, so the single required check passes regardless of the label, and the queued pull request merges.

Desired behavior:
Per the chosen option: a held pull request is either ejected from the queue or fails the required check on its merge-group run, or the operator procedure is documented where operators and lanes read the hold convention.

Key interfaces:

• The required ci-status check and its pull-request contract step on merge_group events.
• The do-not-merge hold convention in the loop-lane docs.

Acceptance criteria:

• A test or recorded run shows a PR labeled do-not-merge after enqueue does not merge (options 2 and 3), or the hold convention documents the dequeue step (option 1).
• Merge-group runs for unlabeled PRs still pass.
• Any change to the shared pr-contract composite lands in ci-workflows first and is consumed here by SHA bump.

Out of scope:

• Changing the merge-queue ruleset itself.
• Other contract checks (title, issue linkage) on merge-group runs.