Lite: prove the Agent-status SQL, not just the decision it feeds

[erikdarlingdata]

Tests only. No production code — the shipped query passes as written.

Follow-up to #1725, which I duplicated: I was assigned the same header-honesty job and #1725 landed first. My PR (#1723) is closed as superseded — theirs is complete and I was not going to replace working shipped code with a parallel implementation of the same thing. This is the one piece that was genuinely missing from both.

What was untested

#1725's tests all run against constructed AgentStatusRow values. That is the right shape for pinning what a row means, but it leaves the query that produces those rows unproven — and it is not trivial SQL. ever_seen_running is a window aggregate that must see the whole retained partition while the surrounding query collapses to the newest row per server.

Both ways that goes wrong return a plausible boolean and pass every model-level test:

• Collapse to the newest row → a server that ran Agent yesterday and stopped today reads "never ran Agent", so a genuine outage renders neutral. That is precisely the failure Lite Job History Agent indicator stops calling absence of signal a problem #1725 exists to prevent, reached from the other direction.
• Leak the partition → one real server's history makes every Agent-less container read as a server that runs Agent, putting the red "Stopped" back exactly where Lite Job History Agent indicator stops calling absence of signal a problem #1725 removed it.

What this adds

Six real-DuckDB round-trips through GetAgentStatusAsync:

Case	Guards
Ran, then stopped → IsAgentProblem	the collapse-to-newest-row failure
No retained row ever ran → not present	the gate actually engaging
Two servers, one with history → per-server	the partition leak
Two rows, newest is stale → unknown (stale)	tiebreak + collection_time
Fresh reading → not suppressed	the gate not over-firing
Fleet read → both columns populated per server	the multi-row path

Plus a pin that the stale window stays longer than the collector's own cadence, read from CollectorScheduleDefaults so it follows a retune.

That last pin is a live trap, not a hypothetical

The shared ServerHealthThresholds.StaleThreshold is 2 minutes, derived from the fastest collector's 1-minute cadence. It looks exactly like the thing someone should unify AgentStatusRow.StaleWindow with. But agent_status collects every 5 minutes, so adopting it would render a perfectly healthy Agent as unknown (stale) most of the time. The pin fails if anyone tries.

Verification

• Lite.Tests full suite: 1510 passed, 0 failed.
• Confirmed non-vacuous by mutation — I changed the shipped query's OVER (PARTITION BY server_id) to OVER () and re-ran: 2 of the 6 fail. Restored and re-ran the full suite green. A test that cannot fail is not evidence, and these are load-bearing enough to be worth checking.
• No production file touched — git status shows one new test file and the CHANGELOG.

Note for whoever coordinates this

Two of us built the same fix in parallel. Worth a look at how the item was assigned, since the duplicated effort was real. Convergent detail worth recording though: independently, #1725 and I both landed on a 30-minute window mirroring the headless service, the same !IsStale && !AgentRunning && EverSeenRunning rule, and the same MAX(CASE WHEN agent_running THEN 1 ELSE 0 END) OVER (PARTITION BY server_id) derivation. When two implementations agree that closely the design is probably right.

🤖 Generated with Claude Code