source-control: D6's reachability gate hardcodes origin, regressing the skill's non-origin and triangular-fork support

[kyle-sexton]

Escaped from #2262: the merged D6 verify-commit-pushed gate (0.51.12, merge 9daeecb) writes
git fetch origin <branch> && git merge-base --is-ancestor <fix-sha> origin/<branch> into
reference/review-discipline.md (line ~233) and skills/pull-request/SKILL.md (line ~181).

Codex raised this as P1-2 on #2262 (thread: #2262 (comment)) and the PR merged before the fix landed; the fix commit 5a94f502 exists on the recreated fix/2244-d6-presence-read branch but is not on main.

Why it is a defect

The hardcoded origin is new in 0.51.12 — base 78dbb10e greps clean for git fetch origin in both files. The same skill pushes through push-branch.sh / resolve-remote.sh --push, which support branch.<name>.pushRemote, remote.pushDefault, non-origin tracking, and triangular fork flows. On such a checkout:

• a successful push to a vendor/fork remote is followed by a fetch of the wrong remote → false D6 failure, blocking D7 and thread resolution;
• an origin base repo carrying a same-named branch verifies the wrong ref entirely.

Same defect family the 0.51.12 change itself targeted: a check that answers confidently about the wrong thing.

Fix

Route the gate through the existing resolve-remote.sh --push (reuse, not reimplement) and compare against FETCH_HEAD — exactly what the resolved remote just served:

REMOTE=$(bash "${CLAUDE_PLUGIN_ROOT}/skills/pull-request/scripts/resolve-remote.sh" --push <branch>) \
  && git fetch "$REMOTE" <branch> && git merge-base --is-ancestor <fix-sha> FETCH_HEAD

Fold in two non-blocking wording corrections the #2262 verifier flagged in the shipped 0.51.12 CHANGELOG entry: "matching the reachability primitive … verify_fix_commit" overstates (that helper uses the fork-aware compare API, not git merge-base — same guarantee, different mechanism), and babysit_gh.py's per_page=100 lives at fetch_paginated_api's call sites, not adjacent to the --paginate flag.

[kyle-sexton]

Skip — covered by open PR #2312 (Closes #2310; same D6 origin regression as #2307).

[kyle-sexton]

Consolidating #2307 into this issue — I filed it 2.5 minutes before this one for the same regression, from a parallel lane that could not see this one being written. This issue is the better of the two (it carries the Codex thread permalink, notes that fix commit 5a94f502 exists on the recreated branch but not on main, and proposes the sharper resolve-remote.sh --push + FETCH_HEAD form), and PR #2312 links here, so this one stays and #2307 is closed as the duplicate.

Two things from #2307 that are not in this body, carried over so they are not lost with it.

1. The process gap is the more valuable finding

The defect is a two-line fix. How it reached main is not:

time	event
02:07:19Z	#2262 merged
02:10:54Z	Codex posts P1-2 — 3 minutes after the merge
~02:40Z	I apply do-not-merge to an already-merged PR; it can do nothing
later	the independent verifier's verdict is recovered and posted

The finding was neither missed nor overruled. Review ran, verification ran, both were sound — and neither gated anything, because the merge did not wait for either. The verifier was explicit that its APPROVE covered only its five assigned items and that remote resolution "was outside my item set and I did not assess it", so nothing in that verdict contradicted Codex either.

That is the same shape as #2265 one layer down: a requirement computed and then not enforced. Worth deciding whether anything should hold a merge until verification evidence exists on the PR, rather than treating tonight as bad luck.

2. An alternative fix worth weighing against the FETCH_HEAD form

This issue proposes resolving the push remote and comparing against FETCH_HEAD, which is correct and reuses the existing seam. A second option avoids the local-remote question entirely by asking GitHub about the PR's own head repository:

gh api repos/{head_owner}/{head_name}/compare/{sha}...{head_oid}
# reachable when status in ("identical","ahead") and behind_by == 0

That is already implemented, already tested, and already this repo's reachability predicate — babysit_resolve_thread.py:603, gated at :628. This issue already notes that helper uses the fork-aware compare API rather than git merge-base; the point here is that adopting it for D6 as well would make the prose gate and the script gate agree on transport as well as semantics, and would be inherently fork-correct without needing remote resolution at all.

Not arguing for it over the FETCH_HEAD form — FETCH_HEAD keeps the check local and offline-capable, which has its own merit. Recording it so the choice is made deliberately rather than by default.