fix(list-recent-runs): recover dropped cron ticks via previous-run anchor

[tend-agent]

Problem

list-recent-runs.sh anchors its completion window to the most recent intended cron tick and floors it at intended - 3600. This tiles exactly — [intended-1h, intended] then [intended, intended+1h] — only when consecutive cron ticks actually fire. GHA doesn't just delay scheduled ticks (which the tick-anchoring in #526 handles well); it drops them. A dropped tick leaves that hour's completions in the gap between the previous and next cycle's windows, and no run ever analyzes them.

#526 named this exact "skipped-tick edge case" and deferred it as "rare under sustained outage," because the only fix on the table then was the 2h-overlap approach the maintainer had rejected for re-analyzing runs. This run is direct evidence it is not rare and the miss is invisible — a dropped tick produces no error, so the skipped outcomes just never get audited.

Evidence (this run)

Analyzing max-sixty/worktrunk, review-reviewers fired at 07:50Z (07:47 tick) then 09:46Z (09:47 tick) — GHA dropped the 08:47 tick. The window for the 09:47 cycle floored at 08:47, leaving [07:47, 08:47] covered by no cycle. list-recent-runs.sh returned 3 of the 10 tend-* runs actually in [07:47, 09:47]. The orphaned hour contained real, substantive bot output:

• worktrunk#3355 — a well-sourced answer on Windows Defender code-signing (comment 4874219842, 08:16Z).
• worktrunk#3357 — a full review cycle: COMMENTED flagging codecov/patch, author pushed coverage, bot APPROVED on the fixed commit (08:15Z–08:23Z).

Both were healthy outcomes this time — but had either gone wrong, no review-reviewers cycle would have caught it. (I covered the gap manually for this run's audit; the gist records the full window.)

Fix

Floor the window at the previous actual completed run's intended tick instead of assuming the previous tick fired. #526's discussion weighed only two options — the intended fire time (not exposed by GHA) vs 2h overlap (rejected) — and missed a third: the previous run's own start time is queryable, and rounding it down to its cron tick recovers exactly where the last cycle's window ended.

• Every tick fires → previous intended tick == intended - 3600 → byte-identical to today's behavior, no overlap (the constraint fix(list-recent-runs): anchor completion window to intended cron tick #526 set).
• A tick was dropped → floor reaches back to the last actual run's tick, covering the orphaned hour with no double-analysis.
• Capped at 6h reach-back so a sustained outage can't create an unbounded window. Falls back cleanly (gh failure, no GITHUB_WORKFLOW) to the current floor.

Verified in this CI session: the patched script returns all 10 in-window runs (was 3); with consecutive ticks it resolves the floor to intended - 3600 unchanged.

Gate assessment

• Type: targeted fix to one branch of the window logic (not a structural rewrite).
• Classification: structural + deterministic — a dropped tick always produces the gap; not a stochastic model lapse.
• Occurrences: 1 confirmed gap-with-missed-outcomes this run. Below the normal 2–3 bar, but acted on because the failure mode is self-concealing: future cycles use the same window and won't re-detect the gap, so evidence cannot accumulate — "wait for occurrence 2" would sit at 1 while silently under-covering. This is tend's own audit tooling, the fix reduces to a no-op in the common case, and human review is the backstop.

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