pr merge: a completed-but-skipped check is reported as 'checks still running', so the gate can never pass

[laynepenney]

gr pr merge refuses with checks still running for a check that has
completed with conclusion: skipped.

Measured on a real PR in this repository (#917):

check run:  sync-status   status=completed   conclusion=skipped
GitHub:     mergeable=MERGEABLE   mergeStateStatus=CLEAN

Control: the base branch's head commit carries 18 check runs through the same
API path, so the query finds checks when checks exist. GitHub itself
considered the PR clean and mergeable.

Why this is worse than a nuisance. A skipped check never becomes green, so
the gate can never be satisfied by waiting — the only exits are --force or
--skip-gate checks. A gate that cannot pass trains people to reach past it,
and --force waives mergeable along with everything else. So a
misclassification in the least important gate quietly disarms the most
important one. This is the same shape as a gate whose underlying quantity is
structurally always zero: it fails identically on a healthy PR and a broken
one, which carries the same information as always passing.

Fix: treat a check run as blocking only when status is not completed.
A completed run with conclusion in {skipped, neutral} is not running and
must not be reported as running; {failure, timed_out, cancelled, action_required} is a real block and should say so with the conclusion named,
not with "still running".

Also worth doing: print the check name and its status/conclusion in the
refusal. checks still running gave no way to tell a queued suite from a
skipped no-op without going to the API by hand.

Not a regression from #917; found while merging it.

[laynepenney]

Cause, from the source, and one reason to prefer a slightly wider fix than the one proposed above.

CheckState (src/platform/types.rs:151) has three variants:

pub enum CheckState {
    #[default]
    Pending,
    Success,
    Failure,
}

A conclusion of skipped has no representation here, so it takes the #[default], which is Pending. resolve_check_status (src/cli/commands/pr/merge.rs:34) then maps CheckState::Pending to CheckStatus::Pending, and the gate prints checks still running. Searching src/ for skipped or neutral returns nothing outside unrelated Gerrit-manifest code, so this is an absent mapping rather than a wrong one.

That matters beyond skipped. Because the unrepresented case falls to a blocking default, every conclusion the mapping does not yet handle — neutral, cancelled, action_required, and anything GitHub adds later — becomes a permanent, unpassable gate rather than a visible unknown. CheckStatus::Unknown already exists one layer up and already warns and proceeds rather than refusing, which is the behaviour an unrecognised value should get.

Worth noting resolve_check_status already carries exactly this reasoning for a neighbouring case: when no CI is configured at all it returns Passing, with a comment saying there is nothing to wait on (#772). A completed-but-skipped run is the same category and lands in the opposite bucket only because the enum cannot express it.

So alongside gating on status != completed, consider making the default non-blocking, or dropping #[default] from CheckState so an unmapped conclusion has to be handled explicitly at the boundary rather than silently becoming "still running".

resolve_check_status is documented as pure and synchronous specifically so it can be pinned against synthetic values without HTTP, so a witness for each conclusion is cheap.

Observed again today on PR #923 (sync-status, COMPLETED/SKIPPED, GitHub CLEAN/MERGEABLE), which needed --skip-gate checks to merge. #904 was the same defect filed a week earlier and is now closed as a duplicate of this issue.