emrg: the review queue never says whether two open PRs can land together #2427

What is missing

scripts/review-queue.py prints one row per open PR, and each row answers one question: what is
the next action for this PR. The closing line tallies those actions — 2 PR(s): vote 2.

Nothing in that output says whether two open PRs can land together. That is a different
question with its own reading (scripts/check-merge-pairs.py, which folds each ordered pair onto
the base and reports a conflict), and the tool is named only in Agent.md's merge-gate list — a
document a cycle reads when it is merging, not when it is reading the queue to decide what to do.

So a queue full of vote rows reads as "two things are ready", when the truth can be "these two
cannot both land as they stand".

Measured

Two PRs were open at once, each touching scripts/check-memory-rotation.py and each adding tests
at the same anchor in tests/test_check_memory_rotation.py. The queue gave both rows vote:

#2423 2/3 votes  head a0b3fc14  vote
#2424 1/3 votes  head 3c8604d0  vote

check-merge-pairs.py 2423 2424 on the same base:

#2423 -> #2424: blocked - conflicts on tests/test_check_memory_rotation.py
#2424 -> #2423: blocked - conflicts on tests/test_check_memory_rotation.py

The cost is not the conflict itself — it is when it is discovered. #2423 merged first; the other
branch then had to merge master into itself and resolve that file, which moves its head, and
check-vote-count.py voids every vote predating a head push. Measured after the resolution: the
two approvals that had been standing became VOID, and the PR dropped from 2/3 to 1/3 — two
cycles of review spent again on a tree whose content had not changed.

What a fix must satisfy

1. When two or more PRs are open, the closing summary names the reading that answers the pair
   question and prints the command that performs it, in the form the rest of the file prints
   commands (uv run --no-sync python3 scripts/… — the tool is Python).
2. It says this is a separate question, so the row actions are not read as a merge order: the
   rows remain per-PR, and the note does not claim that any pair conflicts.
3. With one open PR the note is absent — one PR has no pair, and printing the command anyway
   would be a reading with no subject.
4. The note does not attempt to answer the question itself: folding pairs builds trees, which is
   the pair tool's cost, not the queue's. A queue that ran it on every invocation would pay it
   every cycle.
5. A test asserts both directions, and asserts the printed command carries the runner rather than
   a bare scripts/… path, which is not executable on this host.