Python CI gate: gh pr checks --json ...,headSha always fails ("Unknown JSON field"), so every watch returns status="error" #159

Summary

The Python CI watcher (swe_af/execution/ci_gate.py, watch_pr_checks) always requests

gh pr checks <n> --json bucket,state,name,workflow,link,headSha

gh pr checks --json has no headSha field. gh rejects the whole call with no JSON on stdout, so _parse_checks gets nothing and the watcher returns status="error" on the first poll. _run_ci_gate treats error as terminal, so the CI gate never watches checks and run_ci_fixer is never reached, even when no head_sha is passed (fresh build() PRs).

The Go port already fixed this. go/internal/cigate/watch.go requests only bucket,state,name,workflow,link and explains that requesting headSha "previously turned every watch into status="error"". The Python path still has the old field list.

Reproduction

gh 2.100.0 (2026-09-03), on any PR with checks:

$ gh pr checks 10 --json bucket,state,name,workflow,link,headSha
Unknown JSON field: "headSha"
Available fields:
  bucket
  completedAt
  description
  event
  link
  name
  startedAt
  state
  workflow

$ gh pr checks 10 --json bucket,state,name,workflow,link
[{"bucket":"pass","name":"check_docs","state":"SUCCESS","workflow":"CI", ...}, ...]

Watcher result recorded by a real build() run (Python node, main at 4d1f11c):

{"status":"error","pr_number":9,"elapsed_seconds":0,"failed_checks":[],
 "summary":"`gh pr checks` failed: Unknown JSON field: \"headSha\"\nAvailable fields: ..."}

Impact

• The post-PR CI gate added in feat: post-PR CI gate — watch, legitimate-fix, promote to ready #57 / fix(resolve): anchor CI watcher to new HEAD SHA + startup grace #60 is a no-op on current gh. Failing checks are never fed to run_ci_fixer.
• The build still reports succeeded, so a driver that merges successful builds can merge PRs whose CI is red, without anyone noticing.

Suggested fix

Mirror the Go port: use fields = "bucket,state,name,workflow,link". The existing "no check carries a headSha" fallback then gives PR-level verdicts, as intended.

If per-commit anchoring for resolve() is still wanted, one option is comparing gh pr view <n> --json headRefOid with the expected SHA before accepting a verdict. gh pr checks itself can't provide it.

A unit test where the fake runner rejects unknown --json fields, as real gh does, would catch a regression.