Teach the compliance and agent-review scripts to resolve a PR from a merge_group event

[plamber]

Problem

Stage 2 of the Upgrade Plan wants a merge queue on the organisation ruleset. It's the one
deliverable in that stage genuinely unstarted -- confirmed by reading the org ruleset directly
(main: PR review + compliance check required, id 23431100): its rules list has no
merge_queue entry.

pr-review.yml's own header comment already documents why it can't just be turned on:

merge_group is deliberately NOT here. Neither reusable workflow can serve a merge group
today: pr-compliance.mjs reads event.pull_request and exits 1 when it is absent, and
pr_agent_review.yml maps INPUT_PR_NUMBER from github.event.pull_request.number, which is
empty in a merge group.

What actually needs deciding, not just coding

pr-compliance.mjs's checks split into two kinds, and a merge_group event can only cheaply
supply what one of them needs:

• Content checks (secrets, el-package-versions, solution-membership, test-folder,
  restricted-paths, react-table, prerelease-pin) read the checked-out tree and the
  baseSha...headSha diff. A merge_group's head_ref -
  refs/heads/gh-readonly-queue/<base>/pr-<n>-<sha> - gives a real checkout to diff against,
  so these can genuinely re-run, and arguably should: the queue's whole point is testing the
  change as merged onto the current main, which can have moved since the PR was last checked.
• PR-metadata checks (pr-title, branch-name) need the pull request's own title/body/
  head.ref/user, none of which a merge_group payload carries. These were already correct
  when pull_request last ran; re-fetching the PR via the API to re-check them is possible but
  wasteful, and skipping them silently is fine only if that's a stated decision, not an
  accident of what was easiest to parse.

pr_agent_review.yml is simpler: pr_number just needs the regex /\/pr-(\d+)-[0-9a-f]+$/
against github.event.merge_group.head_ref, feeding the same /repos/.../pulls/{n} lookup the
script already does.

Acceptance criteria

• pr-agent-review.mjs resolves prNumber from merge_group.head_ref when
  pull_request.number is absent; verified against a synthetic merge_group payload.
• A decision recorded (in this issue or the plan) on what pr-compliance.mjs does with the
  metadata-only checks under a merge_group event: re-fetch and re-check, or explicitly skip
  with a stated reason -- not silently pass because the field is undefined.
• pr-compliance.mjs's content checks run against a merge_group's actual diff.
• on: merge_group added to both reusable workflows' workflow_call callers in every one
  of the sixteen repositories' own pr-review.yml-equivalent file.
• merge_queue added to the organisation ruleset (New-OrgBranchRuleset.ps1 is the
  generator of record; the ruleset must not be hand-edited outside it).
• A real test: two individually-green but conflicting PRs queued together, the second is
  rebuilt by the queue and fails before reaching main -- the plan's own Stage 2 exit check.

Not in scope here

Deciding whether strict_required_status_checks_policy or queue batch size need retuning once
real queue wait times are measured -- that's a weekly-review question once the queue exists, not
a prerequisite to building it.

[plamber]

Decision, 24 September: deliberately deferred, not abandoned.

The plan's own Risks table already flags why: Collaboration's PR check runs close to 20
minutes, and a merge queue makes every batch retry cost that. Enabling the queue before Stage 5
(CI hygiene) shortens that check means the first real conflict it catches costs someone a
20-minute wait — exactly the kind of friction that teaches people to route around a new
guardrail rather than trust it.

Sequencing: build this once Stage 5's shared ci_dotnet.yml work has actually landed and
Collaboration's check time is measured down, not before. Re-open this as active work at that
point rather than treating "Stage 5 done" as an unrelated milestone that happens to also unblock
it -- the two are linked by this specific reasoning, not just plan ordering.

[plamber]

Status update: the deferral trigger is now met, not just close.

Stage 5's shared ci_dotnet.yml work has landed (#100, closed 2026-09-24 -- all five repos
including Collaboration migrated, verified passing). Collaboration's real PR check time is now
measured at ~9-10 minutes across three recent merged PRs (#4371, #4390, #4411), down from the
~20 minutes that motivated the deferral.

Marking this unblocked, per the deferral comment's own instruction to reactivate once both
conditions hold. Not starting the implementation itself in this pass -- just recording that it's
ready to be picked up.