AG fixture: land the secondary_lag_seconds evidence the doc blocks cite (#991)

[erikdarlingdata]

Small follow-up to #1689. Evidence only, no behavior change - one file plus a CHANGELOG entry.

Why

Both the collector doc block on dev and the suspended-row rule in flight now cite tools/ag-fixture/VALIDATION.md for the claim that secondary_lag_seconds reports staleness rather than time since suspension, and that a suspended row can still read 0 for a sample or two. Those measurements were taken but never landed - #1689 was merged while I was still measuring, so the two commits after the merge were orphaned on the branch. This lands the half that is still needed.

What it adds

@ag-alerts-builder reproduced the lag accrual independently on the fixture but measured it starting near 3993 where I measured 0. Their redo_queue_size was 0 throughout - an idle AG, where mine was under write load. Re-testing the idle case explicitly reconciles both:

idle, NOT suspended       lag=0    (373s since last hardening - still 0)
idle, NOT suspended +20s  lag=0
idle, suspended +15s      lag=0    NOT SYNCHRONIZING
idle, suspended +30s      lag=450  (secs_since_hardened 424)
idle, suspended +45s      lag=465  (secs_since_hardened 440)
after resume              lag=0

While movement is active the column reads 0 no matter how long the group has been idle. Once suspended it latches onto roughly now - last_hardened_time and climbs. Under load last_hardened_time is always near-now, so it starts at ~0 and looks like time-since-suspension; on an idle group it starts at however long since the last write. Same behavior, different bases - neither measurement was wrong.

Two consequences, both now recorded next to the numbers:

• On an idle AG a lag rule fires instantly on suspension with a large value reflecting idleness, not data at risk. The magnitude is staleness; log_send_queue_size would be the volume measure and it is NULL while suspended.
• It does not latch when movement stops. At +15s suspended it still read 0 while already NOT SYNCHRONIZING. That window is exactly why "a suspended row may raise an alarm but may never clear one" is the only safe rule - a rule reading that 0 as caught-up would clear an alarm mid-fault.

What I deliberately dropped

I had also corrected the collector's doc comment on the old branch. That commit is dropped as redundant - feature/991-ag-suspension-semantics already carried the same refinement into AgDatabaseReplicaStatesCollector.cs and went further (the four *_time columns freezing, the never-cross-check rule). Pushing mine would have collided with two in-flight branches editing that file. Nothing here touches any collector, so this cannot conflict with them.

Test plan

• Idle-case measurements taken on the running fixture, and they reconcile the two prior datasets rather than contradicting either.
• Cherry-picked clean onto current dev; single file, no collector or app code touched.
• No overlap with feature/991-ag-lag-semantics or feature/991-ag-suspension-semantics - neither touches tools/ag-fixture/.

Fixture is still up and healthy: ag1 localhost,14331 (primary), ag2 localhost,14332.

🤖 Generated with Claude Code