Confirm ci-status's GITHUB_TOKEN can disarm auto-merge on a lanes push, and test the queue lookup by behaviour #9471

Problem

#9450 adds a step to ci-status's lanes-hold step in .github/workflows/pr-require-checks.yml. On a synchronize event for an armed lanes App pull request, it calls disablePullRequestAutoMerge with the job's GITHUB_TOKEN. That token has contents: read and pull-requests: write.

Nobody has confirmed that this token can disable auto-merge:

• GitHub's docs say people with write permission, and the PR author, can disable it.
• peter-evans/enable-pull-request-automerge documents pull-requests: write plus contents: write.

A failed disarm only warns (::warning::). Two checks back it up:

• the merge queue's check for a pr-verify PASS at the exact head it merges;
• enable-auto-merge's scheduled reader, which disarms within 15 minutes.

If the token cannot disarm, the push-disarm is dead code on every push.

To do

1. Confirm it live. Watch the first push to an armed lanes App pull request after fix(pr-merge): require a pr-verify pass before a lane pull request merges natively #9450 merges. One of two things shows up in ci-status's Fail a lanes App pull request its body or a member holds step log:
   • the "native auto-merge is off" line, which means the token can disarm;
   • the warning, which means it cannot.
2. If it cannot (S1): choose between these, and do not widen ci-status's permissions without an owner decision:
   • drop the step;
   • move the disarm to a job that holds a token that can disarm.
3. S3: test_verify_rules_sync.py TheQueueCheckAndTheGateAgree.test_the_lookup_names_and_origin_are_the_gate_s checks the workflow body's source text. Replace it with tests of how the bash body behaves:
   • run it against stubbed reads, as scripts/ci-lanes-pr-hold.test.sh does;
   • give it the gate suite's run records;
   • compare its allow and refuse answers with the gate's.

Refs: #9450