check-vote-count.py tells every blocked PR to "make the branch mergeable" - including one whose checks are merely still running, where the answer is to wait #2067

What is wrong

scripts/check-vote-count.py ends its blocked report with one sentence, printed for every blocked row:

More review does not fix this - the branch or the pull request has to be made mergeable first.

That sentence is true for a conflict. For most other blocking shapes it is false, and for one of them it inverts the remedy.

Measured (2026-10-11, cycle cyc20261011-002826)

Both open PRs of the day were in that shape:

$ uv run --no-sync python3 scripts/check-vote-count.py 2064 2066
#2064 BLOCKED 0/3 valid votes (head 1383405b, pushed 2026-10-10T16:28:35Z)
    merge state: MERGEABLE/UNSTABLE
#2066 SHORT 0/3 valid votes (head cc3f7301, ...)
...
#2064: merge state is UNSTABLE - the head's checks are not all green (test-windows: in_progress, test: in_progress).
#2064: More review does not fix this - the branch or the pull request has to be made mergeable first.

Every check-run on #2064's head is still running. The rulebook's action for that state is park — read the row again next cycle — and nothing about the head is fixed by producing a mergeable branch. Worse, the instruction the sentence gives is destructive: a push publishes a new head and voids every vote standing on it, which is exactly what the sentence printed directly after it warns about ("where clearing this state means publishing a new head, that voids every vote standing here"). The output contradicted itself.

The same sentence is wrong, one degree more quietly, for:

• DRAFT — clears by being marked ready, which publishes no commit;
• BLOCKED (protection rules / required reviews) — clears with a review, which publishes no commit;
• no CI run for the head — clears by re-triggering the workflow, which publishes no commit.

Verdict.block_reason already distinguishes these causes correctly; only the printed remedy collapsed them back into one.

Remedy

Print the remedy per cause, from a Verdict.block_cure property read in the same order as block_reason, and name each PR against the cure that applies to it (grouped, so PRs sharing a cause are named once). Each cure says whether it publishes a new head, because that is the fact a voter needs before acting on it.

Verified both directions: fixtures for all seven blocking shapes (conflict, behind, review required, draft, check running, check red, no CI run, plus a head whose check-run list came back empty) fail on the current code and pass with the change; the three new test arms were run against the unmodified script first and all three failed there.