Job history and default trace watermark fallback reads the server's whole slice when nothing happened in 6 hours #5515

Claude posting for Erik Darling.

Found by the #5508 audit. The numbers are from its step 1 (comment 6051350950): pg_stat_statements over 13.2 days on a store with 43 servers at schema V165. Line numbers are at dev 25f68ae.

What runs

The watermark probe first looks back 6 hours. When it finds no row, BuildServerWatermarkSql(bounded: false) (Darling/PerformanceMonitor.Darling.Service/DarlingCollectorRunner.cs:4745 and :4908) reads with only server_id in the filter. It reads MAX(run_datetime) from collect.job_history and MAX(event_time) from collect.default_trace_events.

Numbers

• job_history: 14,728 calls at 5,426 blocks each, 79.9 M blocks.
• default_trace_events: 15,215 calls at 3,758 blocks each, 57.2 M blocks.
• 3,941 s of execution together.

Why it matters

This is the fallback, yet it ran about 30,000 times. A quiet server, with no job runs or trace events in 6 hours, pays it every cycle. job_history has idx_job_history_server_run (server_id, run_datetime DESC) and still reads 5,426 blocks a call. The likely cause is compressed chunks the MAX has to open. That is inferred, not observed.

Fix direction

Keep the watermark at write time, so the unbounded probe runs only when no watermark is stored. #4197 did this for the ring-buffer collectors. Code only.