[umermjd11]

Summary

First stage of the merge queue rollout agreed in Discussion 208 (Option 2).

Adds a merge_group trigger to ci.yml, so CI OK reports on the merge queue's temporary gh-readonly-queue/* branches. It has to land before the develop ruleset requires the queue, otherwise the queue waits forever for a check that never runs. It does nothing until the queue is turned on.

Verification

• ci.yml parses: triggers are pull_request, push and merge_group; jobs are unchanged (solidity, python, docs, ci-ok).
• No job or script in ci.yml reads PR-only event data.
• Concurrency needs no change: queue runs have no PR number, so they fall back to a group keyed on run ID, and cancel-in-progress stays off for them.
• CI OK is the only required check, and full-gi.yml is manual-only, so no other workflow needs the trigger.
• Not tested here: this PR can't show CI OK firing in the queue, because the queue doesn't exist until the ruleset switch. The first real PR through the queue is that check. If it sticks, revert the ruleset change.

Next stage (not in this PR)

• develop ruleset: require the merge queue (merge commits only) and remove "require branches to be up to date".
• Update Developer/MAINTAINING.md and the din-pr-merge skill.

PR No. 296 adds workflow_dispatch at the same spot in ci.yml, so whichever lands second gets a small conflict.

Part of Discussion 208.

🤖 Generated with Claude Code