Seed the restart-row index plan test on a fixed day

[erikdarlingdata]

What failed and when

RestartRowIndexLiveTests.EachReader_PlansOnItsPartialIndex_OnAnUncompressedChunk_AndReturnsExactlyTheRestartRows failed in the 01:20 UTC nightly: Assert.Empty() Failure: Collection was not empty Collection: ["Seq Scan on _hyper_29_2_chunk"].

Cause

The seed gives each of its 5,000 rows a time g seconds before the real wall clock, so it covers the last 83 minutes. Chunks are one day, aligned to UTC midnight. Between 00:00 and about 01:23 UTC the seed therefore lands on two daily chunks. In the 01:20 run, the older chunk held about 200 rows, and on a chunk that small a Seq Scan costs less than the partial index, so the no-heap-scan assertion failed. The same defect was fixed for the legacy-row test in #5061.

Fix (test only)

• The seed ends at a fixed past instant, 2026-01-15 23:50 UTC, so the whole seed sits in one day.
• A guard requires that no seeded row falls before the anchor's date in collect.query_stats and collect.procedure_stats (the seed sits in one daily chunk), and still requires at least 1,000 rows.
• The two plan assertions print the plan JSON on failure.
• No production file changes.

Test plan

• The plan flip itself did not reproduce locally: on the unchanged test, with the clock set to 00:02, 00:05, 00:20, 01:20, 01:30 and 01:55 on 2026-10-04, the fact passed on a local PG18 + TimescaleDB 2.30.1 store, which kept the index. The CI failure's plan names the second chunk. The guard below shows the two-chunk seed deterministically.
• GREEN: RestartRowIndexLiveTests run 3 times, 3/3 passed each time. TuningStartPathOneBuildTests 5/5 and QueryStoreLegacyRowIndexLiveTests 2/2 passed. Darling.Tests builds with 0 warnings, 0 errors.
• Guard proof, each temporary and reverted: with the anchor at 2026-01-16 00:30 the class failed with collect.query_stats has 3200 seeded rows before 2026-01-16; the seed must sit inside one daily chunk; with the anchor at 2026-01-16 01:20 it failed with collect.query_stats has 200 seeded rows before 2026-01-16; the seed must sit inside one daily chunk.

Other live plan tests seeded from the wall clock

Census: Darling/Darling.Tests/*LiveTests.cs files that both use DateTime.UtcNow and assert on a plan. I read the seed lines only, not every test body. Only this class is changed.

• AnomalyObjectStatsLatestSnapshotsLiveTests.cs:72-73 (EXPLAIN at :114): seeds a snapshot at now and one at now-2 days. Rows are few; chunk placement near midnight could vary. Possible.
• StoreMetricsLatestSkipScanLiveTests.cs:82 (plan assertion near :133): a month of hourly history ending at now, 720 rows per object. The newest chunk can be small just after midnight. Possible.
• QueryStoreBackgroundIndexesLiveTests.cs:196 (Assert.DoesNotContain("Seq Scan", ...) at :286): reads end at now. Possible if its seed also ends at now; not checked.
• DarlingWatermarkFloorPlanShapeLiveTests.cs:83: 30 days of daily rows from now. One row per day, so the span crosses midnight by design; the assertion is a bounded chunk count, not a Seq Scan check.
• JobHistoryPerServerTopNLiveTests.cs:202,258,416 and JobHistoryWatermarkEpochLiveTests.cs:160,161,212: seeds from now back hours to days; spans cross midnight by design. Their plan assertions are Index Scan and no extra Sort, which do not depend on chunk size as far as I read.
• CollectionLogSegmentByLiveTests.cs:95,162,463, ParameterSensitiveDrillDownTextLiveTests.cs:174, PlanRegressionDrillDownReuseLiveTests.cs:88, TopCpuQueriesTextLiveTests.cs:143: a 4-hour window ending now (the last four); it crosses midnight for the first 4 hours of each UTC day. They use EXPLAIN ANALYZE plan inspection; whether the assertion is chunk-size sensitive was not checked.
• QueryStoreBackfillCutChunkLiveTests.cs:215: already waits until the floor is clear of midnight, so it is safe.
• PlanSync4530*LiveTests.cs, PgPlanCapture*LiveTests.cs: "Index Scan" there is plan XML text or a single stamp, not a planner choice. Not at risk.
• QueryStoreBackfillCandidateLiveTests.cs: uses a fixed anchor already.

CHANGELOG entry

None: test-only change.

SECTION: None