fix(running-in-ci): make the CI-monitor poll cap terminal

[tend-agent]

Problem

The gated CI poll in CI Monitoring caps at ~9 minutes, but nothing says the cap is the whole budget. Two tend-review sessions on max-sixty/worktrunk have now hit the cap and simply run the loop again — three full passes each, ~28 minutes of post-approval polling — because re-entering reads as diligence rather than as waiting on something that already proved it won't settle.

It can't settle. pending() deliberately reads the whole statusCheckRollup rather than --required, so it counts advisory jobs too. worktrunk's nightly workflow runs feature-powerset and benchmarks for 80+ minutes on a PR head — the repo's own overlay documents the benchmark job's runtime — so on any PR that triggers them pending() structurally cannot return 0 inside a 9-minute cap, no matter how many times the loop is re-entered.

Evidence

Run	PR	Approved	Poll passes	Ended	Still pending at exit
31086241862	#3748	08:48:33Z	3 × 9 min (08:48:41Z → 09:16:19Z)	09:16:37Z	feature-powerset (started 08:49:11Z, still running an hour later)
30833412090	#3721	16:56:51Z	3 passes, ~26 min beyond the first	17:33Z	feature-powerset, codecov/patch (never registered)

In run 31086241862 every required check was terminal by 09:00:25Z; the remaining 16 minutes of polling watched one advisory job. The session's own log shows it saw feature-powerset IN_PROGRESS on all nine iterations of the final pass and then ended with the reasoning "One non-required nightly job, feature-powerset, was still running when I hit the polling cap (~28 min) — I didn't wait it out; it's advisory and a failure there couldn't stem from a comment-only diff." — a sound call, but it stayed in the session log. Step 4 asks for that as a comment; nothing was posted, so the PR carries an approval with no record of what went unverified. The 30833412090 session did post the comment, so the two runs resolved the same state differently.

Change

Step 4 now says the cap is terminal, gives the structural reason (pending() counts advisory jobs, so a long matrix can never reach 0), and specifies what the unverified-checks comment should carry — each pending check, marked required or advisory, with gh pr checks --required named as the source since the rollup the poll reads carries no required flag. An advisory-only tail becomes one cheap line rather than a judgment call about whether to say anything at all.

Gate assessment

• Evidence level: High — consistent across two independent sessions, both traced to the same structural cause. Occurrences: 2 (this run + prior evidence). The prior entry pre-registered exactly this escalation: "Watch for a second, independent run showing the same re-entry before treating as High."
• Structural, not stochastic: pending() counts non-required checks by design (the recipe explains why it avoids --required), so any repo with a long advisory matrix reproduces this on every gated poll.
• Change type: targeted fix — one numbered step, no new section. Normal bar, met.

Not covered elsewhere

#821 addresses the pre-APPROVE rollup guard in review/SKILL.md (provenance of a stale red when the cap expires); this is the post-approve dismiss-on-red poll in running-in-ci, where a terminal rule already exists and is being skipped rather than improvised. #870 adds a subsection after step 4 about reviews landing mid-poll and does not touch the step itself.

Evidence log: https://gist.github.com/a88c03f4d0c3fb1791060ff3dd97d1c4

[tend-agent]

Self-authored, so this is a COMMENT rather than an approval. The rule itself lands — "the cap is the whole poll budget, not one attempt" is exactly the sentence the two re-entering sessions were missing. Two things on the wording, plus a merge-order note.

Required-ness isn't derivable from the recipe. The new text asks the unverified-checks comment to name "whether it's required", but the poll deliberately avoids --required (the block comment above pending() explains why) and the rollup it does read carries no required flag. So the step asks for a fact nothing in the section surfaces, and a session will improvise it — the failure mode this skill file spends most of its length guarding against. Naming the source costs a clause; the inline suggestion adds it, along with the caveat the recipe already establishes (an omnibus that hasn't registered yet won't appear in --required output, and is the one most likely to be required).

"A second pass buys nothing" is broader than the mechanism behind it. The mechanism given — pending() counting an hour-long advisory matrix — makes re-entry futile in that case, which is the case in the evidence. It doesn't cover a session gated on its own push whose required suite runs 12 minutes: there a second pass would settle it and let the gated follow-up (fix the red, dismiss the approval) fire, where ending ships a comment and leaves the push unverified. That's not a regression — the old text ended at the cap too — and the trade is defensible given the sessions burning 28 minutes on advisory jobs. But stating it as an unconditional "buys nothing" makes the rule rest on a claim that isn't true in the required-check case; the suggestion drops that clause and keeps the structural reason, which carries the rule on its own.

Merge-order note: #870 inserts a subsection immediately after this step and carries the old step-4 text as a context line, so whichever of the two lands second will need a trivial rebase.