graphite: 🐛 Hold a push when the merge-queue check times out

[yasyf]

Why

no_push_to_a_queued_pr faulted twice in the release-v3 drive on 2026-10-02 around 9:01 PM Pacific:

captain-hook fault: hook no_push_to_a_queued_pr — TimeoutExpired: Command '['ccx', 'vcs', 'pr', 'status', '--json', '29691']' timed out after 15 seconds

A faulted handler is caught and recorded, so the push it was checking went through unverified. That is the outcome this hook exists to prevent.

The slow part is ccx vcs pr status, and it is slow by design. Every ccx process on the machine shares one GitHub poll, spaced at least 30 seconds apart. A reader whose PR is stale sleeps until the next poll slot, then polls every leased PR. Measured on this Mac under a busy drive:

Read	Latency
Cached, or a landed PR	0.03 s
Cold, poll slot free	4.25 s
Cold, another process polled within 30 s	27.0 s, 28.8 s, 29.9 s

The sync hook runs inside a 30-second client request deadline, and dispatch abandons a hook still running 5 seconds before that deadline. An abandoned hook also lets the push through. No budget inside that window covers ccx's worst case, so the fix is to make the timeout an explicit verdict instead of a fault.

What

• Each subprocess the hook runs gets a timeout of whatever the request deadline leaves, minus the sync margin and one second for the verdict. The cold CLI keeps a 45-second cap.
• A timed-out PR lookup or ccx vcs pr status read blocks the push with one line naming the PRs or branches it could not verify, and tells the agent to rerun once ccx vcs pr status answers. A queued PR still gets the existing stacked-PR denial.

Other failures stay fail-open as before. A PR Graphite has not recorded yet still pushes freely.

Testing

• New tests cover a timed-out status read and a timed-out PR lookup, and check that the timeout fits inside the hook deadline. All three fail on main and pass here.
• pytest tests/test_pack_graphite.py passes, 192 tests.