v0.7.0 — A refused merge method is tried again another way

The gate emits a ranked list of merge methods, and the workflow tries them in order

Whether GitHub accepts a merge method has at least five independent inputs — repo settings, repo rulesets, org rulesets, classic branch protection, and the acting token's App scopes against the PR's changed paths — and two of them are unreadable from a workflow by construction. Classic branch protection needs admin to read, and no permissions: key grants admin; the App-workflow-scope refusal is not a repo setting at all.

So the pre-flight probe is now a prior, never a verdict. gate.cjs emits methods= on every call: the full ranked candidate list (workflow-touching PRs rank merge, rebase, squash; everything else squash, rebase, merge), intersected with what the two readable layers report, and never narrowed by a failed query. The arm step tries the list in order and stops at the first method GitHub accepts.

Escalation only happens when every ranked method is refused, and the escalation carries what GitHub said to each attempt rather than only the first. The incident behind this: a PR sat green and authorized while the gate paged a human about a refused merge commit, with squash and rebase both untried — the ban lived in classic branch protection's required_linear_history, which nothing the workflow can query reports.

The probe reads a third layer where it can

Rulesets now surface required_linear_history in the readable rules response, so where the restriction lives there, the probe narrows honestly (merge commits drop out of the candidates). Where it lives in classic branch protection, the fallback above is what protects the merge.