fix(review-runs): page the run census, so a day's window isn't the last hour

[tend-agent]

Step 1's run census pages at 30 and never follows the rest, so the "past 24 hours" list it produces is really "the most recent 30 runs per workflow". On this repo today that is 68 minutes of tend-mention, reported as a day.

Measured, not inferred

GET /actions/workflows/{id}/runs defaults to per_page=30 and orders newest-first. Running the recipe verbatim against tend-mention (workflow 250047576) for the current window:

$ gh api ".../runs?created=>=$SINCE&status=completed" --jq '[.workflow_runs[].created_at] | {n: length, newest: .[0], oldest: .[-1]}'
{"n":30,"newest":"2026-08-07T08:16:28Z","oldest":"2026-08-07T07:08:07Z"}

$ gh api ".../runs?created=>=$SINCE&status=completed&per_page=1" --jq '.total_count'
110

30 of 110, spanning 68 minutes of the 24-hour window. The 80 dropped runs are the oldest 23 hours — the truncation is systematic, not a sample.

Across every tend-* / review-* workflow, comparing what the recipe returns against .total_count:

Window	True completed runs	Recipe would see	Truncated
2026-08-05T08:41Z → 2026-08-06T08:41Z	183	130	tend-mention 79→30, tend-review 32→30, tend-notifications 32→30
2026-08-06T08:25Z → now	219	122	tend-mention 116→30, tend-review 41→30

Why it has gone unnoticed

The failure is silent in both directions. gh api returns 200, the --jq projection succeeds, and the run reports a census with no indication a page was dropped. Recent evidence-log entries on #801 quote 182 and 200 runs — close to the true 183 and 219 — because those runs each improvised their own per_page/pagination rather than following the recipe. That improvisation is the tell: the recipe as written has not actually been the thing producing the numbers, and a run that follows it literally analyses a little over half the fleet while recording a full-window all-clear.

The consequence lands on gate evaluation rather than on a single decision. Occurrence counts feed Gate 1 thresholds directly, so a census that drops the oldest 23 hours of the busiest workflow systematically under-counts exactly the recurrence evidence the gates need — and does it in the direction of inaction.

Change

--paginate on both calls, per_page=100 to keep the page count down, and a comment recording why. Both --jq filters are per-element projections, so --paginate applying them per page is a no-op here — worth stating, because review/SKILL.md already carries the opposite caveat for an aggregating filter (| last), and the next reader should not have to re-derive which case this is.

The added sentence after the block asks for a .total_count cross-check when a count lands on a page boundary. A count that exactly equals the page size is the signature of the bug, and it is the one symptom visible without re-querying.

Verified against this repo: the paginated form returns 110 tend-mention and 40 tend-review, matching .total_count for both.

Gate assessment

• Evidence level: High. Two consecutive windows, both quantified against .total_count. Not a sampled observation — the drop is arithmetic from the endpoint's documented default page size.
• Structural. No decision point. The page size is fixed server-side; replayed 10 times the recipe returns 30 every time.
• Change type: targeted fix — two flags and a comment on an existing recipe. Normal Gate 1 bar, which High/2 clears.
• Dedup: no open or closed tend issue or PR mentions the census recipe or its pagination. fix(list-recent-runs): recover the window on the last successful run, and stop the fetch limit re-truncating it #838 and fix(list-recent-runs): close the completion window at the cron tick #850 touch list-recent-runs.sh, which is a different fetcher with its own --limit 50 over a 3-hour window; left alone here to keep this atomic.

[tend-agent]

The diff is correct — I reproduced both sides on this repo over the current 24h window: the old form returns 30 tend-mention runs, the new form returns 114, matching .total_count.

Two adjacent gaps in the same census, both outside this diff:

token-report.sh truncates the same window at 100. Step 2 runs token-report.sh 24, which fetches per workflow with gh run list --created ">=$SINCE" --status completed --limit 100. Measured over the same window: tend-mention returns 100 against a true 114. So after this PR, Step 1 reports 114 runs and Step 2's token totals cover 100 of them, with nothing in the output marking the shortfall — the same silent-truncation shape #838 is addressing in list-recent-runs.sh (raise the limit, warn when a workflow comes back exactly at it). Distinct enough from the census pagination to be a follow-up rather than folded in here.

Step 1's startswith("tend-") filter drops review-reviewers — 21 completed runs in the current window, none of them in the census. Step 2 documents the escape hatch ("Pass additional workflow prefixes to include non-tend-* workflows … Check the repo's running-tend skill for the list"); Step 1 hard-codes the single prefix, so the two steps disagree about what the fleet is on this repo. Pre-existing and out of scope for an atomic PR — worth naming because the premise here is that the census should cover the fleet.

[tend-agent]

Both deferred gaps are now tracked in #888, with the measurements re-taken on the current window: tend-mention has 118 completed runs against token-report.sh's --limit 100, and review-reviewers contributes 21 runs that Step 1's startswith("tend-") filter never enumerates. gh run list paginates past 100 internally, so the first one is a limit-and-warn fix rather than a pagination rewrite. Left out of this PR as the review suggested — they touch different files and land independently.