Fix CI gate: use mergeable_state instead of check-runs API

The GitHub MCP list_workflow_runs tool does not support head_sha
filtering, causing the agent to report 'No CI workflow runs exist'
for PRs with all-green CI. The check-runs approach was also unreliable
(only 2 raw API calls reached api.github.com during agent execution;
the rest were proxied through api.githubcopilot.com).

Replace both CI check instructions with a single reliable gate:
  mergeable_state === 'clean'

This field is already on the PR object (pull_requests toolset,
get_pull_request). GitHub computes it from all branch protection
checks. Confirmed: PR#112 and #106 show 'clean', PR#101 shows
'blocked' (failing CI) — exactly the right behavior.

Fix CI gate: use pull_request_read get_check_runs instead of mergeable_state

mergeable_state is lazily computed and goes stale for inactive PRs.
The bulk list_pull_requests call never triggers recomputation, so old
Dependabot PRs always return 'unknown' — causing all PRs to be skipped.

Fix: use pull_request_read with method 'get_check_runs' (pull_requests
toolset) which directly returns check-run conclusions for the PR head
commit. Confirmed 9 check-runs (all success/skipped) for PR#112 and
PR#106 via this API. PR#101 has a failing check-run — correctly skipped.

Fix CI gate: use actions_list list_workflow_runs with branch filter

pull_request_read does not have a get_check_runs method — the agent was
silently falling back to get_status which queries the old commit-statuses
API (returns total_count=0 for GitHub Actions, which uses check-runs).

Fix: use actions_list with method list_workflow_runs, filtered by the
PR's head.ref branch. This is a supported MCP tool method and correctly
returns GitHub Actions workflow runs. Group by name, take latest per
workflow (highest run_number), require all to be completed success/skipped.

Verified: branch filter returns all 3 workflows for PR#106 and PR#112
with success conclusions. Also correctly surfaces old failures (run #213,
#230 on chai branch) while latest runs show success — 'latest per workflow'
logic handles re-runs correctly.

Author: BenjaminMichaelis

.github/workflows/dependabot-major-review.md

@@ -72,7 +72,7 @@ You will fetch and read external content from package registries, changelogs, re
 These rules are absolute and must never be bypassed:
 
 1. **Author verification:** ONLY process pull requests where the author login is EXACTLY `dependabot[bot]`. If the author is anyone else — even if the PR title looks like a Dependabot PR — skip it immediately. No exceptions.
-2. **CI status:** ONLY process pull requests where ALL CI check runs have a conclusion of `"success"` or `"skipped"`. If any check has a conclusion of `"failure"`, `"cancelled"`, `"timed_out"`, `"action_required"`, or is still pending/in-progress/missing, skip the PR entirely.
+2. **CI status:** ONLY process pull requests where all CI workflow runs on the PR branch have passed. Use `actions_list` with `method: "list_workflow_runs"` filtered by the PR's `head.ref` branch — skip PRs with any failing, cancelled, or pending latest runs, or zero runs.
 3. **Version bump scope:** Process PRs that are either (a) a major version bump for a single package, or (b) a multi-package PR (branch name contains `/multi-`). Skip single-package PRs that are pure patch or minor bumps — those are handled by the existing auto-merge workflow.
 4. **Skip already-processed PRs:** If a PR already has the label `ai-approved-major-update`, skip it.
 5. **Rate limit:** Process at most **10** PRs per run. Stop after reaching this limit.
@@ -96,7 +96,7 @@ For each candidate PR, perform the following checks in order. If any check fails
    - Single package: "Bump <package> from <old> to <new>" — parse semver, only proceed if major version increased OR if this is a multi-package PR
    - Multi-package: "Bump <package> in <path>" with a branch name containing `/multi-` — these have multiple packages updated together and `fetch-metadata` returns null for `update-type`. **Always process these** regardless of version increment — the AI must analyze the diff to determine all version changes
    - If the title is a single-package bump where the major version has NOT increased (pure patch/minor), skip it — the existing auto-merge workflow handles those
-4. **CI status:** Use the `actions` toolset to retrieve check runs for the PR's head commit. Verify that every check run has a conclusion of `"success"` or `"skipped"`. If the check-runs endpoint returns 0 results, also query workflow runs by head SHA (`GET /repos/IntelliTect/try/actions/runs?head_sha=<sha>`) — Dependabot PRs often register their CI only as workflow runs, not as check-run objects. Group runs by workflow name and evaluate only the **latest run per workflow** (highest run number) — a successful re-run after an earlier failure is valid. At least one workflow run must exist and the latest run for every workflow must have `conclusion: "success"` or `"skipped"`. If any latest run has failed, is cancelled, or is still in-progress/pending, skip this PR entirely.
+4. **CI status:** Use `actions_list` with `method: "list_workflow_runs"` (from the `actions` toolset), passing the PR's `head.ref` as the `branch` parameter and `repo: "try"`, `owner: "IntelliTect"`. This returns all workflow runs for the PR branch. Exclude runs where `name` is `"Dependabot Major Version Reviewer"` (our own workflow). Group the remaining runs by `name` and take only the **latest run per workflow** (highest `run_number`) — old failures followed by a successful re-run are fine. Every latest run must have `status: "completed"` and `conclusion: "success"` or `"skipped"`. At least one qualifying run must exist. If any latest run has `conclusion: "failure"`, `"cancelled"`, `"timed_out"`, or `"action_required"`, or is not yet completed, skip the PR and report why.
 
 ### Step 3: Verify the Diff is Version-Only