… checks (#179) (#209)

* merge-pr: gate on the PR's checks before merging, and pin the merge to the head it read

`wt merge-pr` and its `--dry-run` said verdict=ok while the PR's checks were
still queued, and when most of its workflows never started. `--admin`, which a
required-review branch needs, bypasses GitHub's required checks too, so
nothing between wt and the merge looked at CI.

A checks gate now runs right after the PR-state precheck, before the deploy
confirm. It reads the head commit's statusCheckRollup in one paged GraphQL
query (not `gh pr checks`: it exits 1 with a stderr sentence for "no checks",
and the raw rollup keeps every re-run, so the newest run of each check is kept
by databaseId), and the base branch's required checks from REST
branches/{base} (readable by any reader) and rules/branches/{base}.
merge.DecideChecks (pure) blocks on a pending check; a failed, errored,
cancelled, timed-out, action-required, startup-failure or stale one; a state wt
does not know; a required check with no run on the head; fewer non-skipped
checks than the new merge_min_checks / WT_MERGE_MIN_CHECKS (or a value that is
not a count); and any failed read. A PR on which no check ran, with nothing
required and no floor, merges with a visible "no check ran" note: whether a
workflow should run on a PR is in its triggers, which wt cannot evaluate, so a
required check or the floor is the deterministic "CI never started" signal.

A blocked verdict is refused non-interactively, asked at a terminal (type
"merge"), and previewed by --dry-run, which always prints the summary line
(checks=green|none|blocked|unread). --checks-ok merges anyway, loudly;
--bypass and --admin never get past it. The merge is pinned with
--match-head-commit to the commit whose checks were read, so a push after the
read fails the merge instead of shipping an unchecked head.

Fixes #179

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* merge-pr: a check that failed stays failed until a later run passes; read the PR's own repo, apps and required workflows

The adversarial review of the checks gate showed it reading a check that
FAILED on the head as passed, plus smaller gaps. Fixed:

- A failure stands until a later run of the check passes. Taking the newest
  run by databaseId let a label event's re-run that SKIPPED a job an earlier
  run FAILED read green. latestChecks now judges runs by workflow run: within
  one, every run counts (the rollup already drops a re-run's earlier attempt,
  measured on cli/cli run 37941363988, so two runs of one name there are two
  jobs, as in pytorch); across workflow runs the newest decides, except that a
  FAILURE/ERROR/TIMED_OUT/STARTUP_FAILURE/ACTION_REQUIRED is cleared only by a
  later SUCCESS, a SKIPPED/NEUTRAL run never replaces a pass, a running run or
  an unknown state, and CANCELLED/STALE give way to anything later.
  cli/cli#14044's SUCCESS then SKIPPED stays green. One state reading
  (ghx.StateKind) now feeds this and merge.BucketOf.
- A check's identity includes its app: two apps posting one name
  (dotnet/runtime) are two checks.
- Required checks come from the PR's base repository on the PR URL's host,
  not the cwd's {owner}/{repo}. A forwarded -R/--repo is followed, so the PR
  merged is the PR read and pinned.
- A ruleset's workflows rule needs a run of that file from that repository
  (workflowRun.file); a run whose file GitHub does not name makes it
  unverifiable, which blocks.
- A required check pinned to an app needs GitHub's isRequired for this PR, or
  a run of that app; isRequired also verifies pinned commit statuses. It adds
  no rate-limit cost (1 point a page either way).
- A passthrough that merges nothing (--disable-auto, --help/-h) skips the
  gate and the pin. --auto stays gated, and the refusal says why.
- A blocked dry run prints `verdict=ok checks=blocked`, never a bare
  verdict=ok, and still exits 0.
- The terminal prompt reads its answer a byte at a time, so a `-F -` body
  typed after it is never consumed.

Fixtures captured with the first query got the new fields read from the same
head commits, so the states they caught are kept; dotnet, pytorch and grafana
fixtures are new.

Refs #179

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

* merge-pr: pin that the checks prompt leaves a `-F -` body for the squash

Mutation testing showed the end-to-end case for "a terminal, then a -F -
body" checked only gh's argv: a prompt that read ahead and swallowed the body
still passed. The fake gh now records its stdin and the case asserts the
typed body reaches gh; TestReadLine pins readLine stopping at the newline.

Refs #179

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>