[rmcdaniel]

Security class: R2. This changes workflow events and required-check coverage (D500).

GitHub's merge queue needs every required Actions check to run on the merge_group event. This PR is preparatory workflow source only. It does not make the queue usable, and repository queue settings stay disabled. D500 train batching remains the throughput mechanism until both activation prerequisites below are qualified.

Stacked on train #723 (base rust-325-train-oct24) so it includes #724's concurrency groups. It retargets to main when #723 merges.

Changes

Workflow	Change
phpunit-feature.yml (PHPUnit feature suite, Repository contracts, policy preflight, feature source qualification)	merge_group: trigger. OPENAPI_BASE_REF/CORPUS_BASE_REF and the Docker-input diff use github.event.merge_group.base_sha for queue groups. Both jobs already fetch full history. The two PHP contract tests that pin these expressions now expect the merge-group base.
server-parity.yml (Shared Server fixtures)	merge_group: trigger. merge_group has no path filter, so a queued group would get the full shared profile.
public-boundary.yml	merge_group: trigger, scanning exactly merge_group.base_sha..head_sha. The push trigger stays unfiltered, so queue branches are also scanned on push.
sonar.yml	Unchanged. The Sonar job receives SONAR_TOKEN, and its fork guard is always true for a merge group. It does not run on merge_group.

tests/Unit/MergeGroupTriggersTest.mjs (Repository contracts) requires all of the above, including that sonar.yml has no merge_group trigger and that the Public Boundary push trigger has no branch or path filter. It passes 7/7. Counterfactual: against the previous head's sonar.yml and public-boundary.yml, exactly those two cases fail.

Activation prerequisites (not in this PR; the queue stays off until both are qualified)

1. A Sonar queue gate that attaches the required result to the exact synthetic merge-group SHA, without giving SONAR_TOKEN to candidate-controlled source, workflow or config. Security is designing and qualifying this.
2. A terminal, fail-closed Shared Server fixtures aggregate on the synthetic head, required by the queue. It needs an ordinary-PR path that always reports instead of leaving a required check pending. This is a follow-up PR.

Trust notes

• No permissions, actions, secrets or sinks are added. Job definitions, budgets and checkout behavior are unchanged; checkout uses the queue group's synthetic head.
• CI: cancel a superseded pull request run of the fixture and PHPUnit workflows #724's concurrency groups key on event and ref, so a queue group gets its own group and is never cancelled. Only pull_request runs cancel superseded heads.
• These PR checks exercise pull_request, not a real merge_group; they cannot prove the queue event contract by themselves.

[rmcdaniel]

General CI/Sonar review of 7c2be04d142aca6e83b56d8cf6f9fc55f458fabd:

The event/base-SHA changes are the right direction. Before enabling the queue, its required checks must also wait for the terminal full Shared Server fixtures result on the merge-group head. The current public rulesets require PHPUnit feature suite and App 12526's SonarCloud Code Analysis; merely adding an independent merge_group trigger to the shared workflow does not make that long workflow a merge gate. Otherwise PHP/Sonar could finish and the queue could merge while shared execution is still running or later fails.

Please provide a required aggregate for the full shared matrix, or have an already-required aggregate depend on it, without leaving path-filtered ordinary PRs waiting forever for a missing required result. Keep the full-profile budgets and evidence unchanged. A negative control should show that a shared-matrix failure or missing result prevents a queue merge even when PHP and Sonar pass; the successful control must refer to the actual merge-group SHA.

For Sonar, the scanner is CI-based in sonar.yml, while the posted check is owned by the Sonar App. Sonar's current OSS documentation supports unlimited branch analysis, so a generic Free-plan branch limitation is not enough to reject this approach. The remaining proof is actual analysis and App check reporting for the temporary queue SHA. I can independently inspect that analysis/gate as the Sonar maintainer once the protected probe is available. No required check is to be removed, renamed into a synthetic pass or replaced by unrelated PR-head results.

This is a source/settings qualification requirement. No queue setting was changed by this review.

[rmcdaniel]

Head c1678a81bd0a1605524b3204dae564ce2a7b1755. This adds the non-privileged contract test Security asked for (D500 comment 19159373): tests/Unit/MergeGroupTriggersTest.mjs, run in Repository contracts. It passes 7/7 here and fails 6/7 against the train head without merge_group. Per Security's decision, this PR is source-only. Repository merge-queue settings stay off until Security qualifies a Sonar-compatible queue gate against an actual temporary merge-group SHA, because SonarCloud Code Analysis comes from the SonarQube Cloud app's automatic analysis and not from a repository workflow.

[rmcdaniel]

General reviewed corrected head 2781a92. The diff now preserves the existing Sonar secret boundary, keeps Public Boundary on every push, and adds the exact merge-group base/range handling to the non-secret workflows. The PR correctly separates source preparation from queue activation. My terminal Shared Server fixtures requirement remains an explicit follow-up: the synthetic head must receive a required aggregate that fails on any failed, cancelled or unexpectedly skipped matrix cell, and ordinary PRs must report a defined no-change result rather than leave a required check pending. This review does not qualify an actual merge_group execution or activate the queue. The exact-SHA Sonar gate and that terminal matrix result remain prerequisites.