MCP: Darling's blocking stats and PostgreSQL deadlock and log event tools say where their data starts (part of #4966)

[erikdarlingdata]

What an MCP client sees

Three more Darling MCP tools carry effective_start (UTC, with a Z), window_truncated and truncation_note right after hours_back on a data answer, and the same keys under hints on an empty answer:

• get_blocking_stats;
• get_pg_deadlocks;
• get_pg_log_events.

What they share with the rest of the family:

• not_collected and the runtime precondition stay bare, decided before any probe.
• A data answer over a window of 90 minutes or less starts no probe.
• A failed probe costs the notice, never the rows.

get_blocking_stats: two series, one notice

The answer holds two separate per-minute series, blocking severity and deadlock severity, so the one notice sits at the LATER of their two start points. That's the rule its Lite twin uses (#5172).

• Within each series: blocking takes the earlier of the blocked process reports' and the DMV blocking snapshots' coverage, because they stand in for each other, the same two sources get_blocking probes. Deadlocks take the deadlocks' coverage.
• Events older than coverage: both series read on event time, and a first collection can store events from before itself. So each series' floor first takes the earlier of its coverage and its own oldest bucket, and only then is the later of the two taken. A series whose collector started inside the window therefore can't hide behind the other's coverage, and its empty head no longer reads as "no deadlocks" or "no blocking".

get_pg_deadlocks and get_pg_log_events: event lists

Both are newest-first, capped lists windowed on the event's own time.

• The floor: the earlier of the coverage probe and the oldest event shown, through the same ReadEventAsync the SQL Server event tools use (MCP: Darling's blocking, deadlock and long query tools say where their data starts (part of #4966) #5171).
• The probe: ForCollectorTable over pg_deadlocks and pg_log_events. Neither is a gated raw relation or a baseline-floored collector, so each has a schedule retention edge and the probe never walks to a table's oldest row.
• The notice is always coverage, whether or not the cap cut the page. The answer already reports the cap through truncated and the oldest returned time.
• The web page: it lists neither read today.

Test plan

• get_blocking_stats, in its live class, with fixed anchors:
  • one series covered from before the window and the other starting inside it, in both orders;
  • the later floor wins;
  • deadlock rows only;
  • XE early and DMV late;
  • both covered, with the key order;
  • an event older than its collection;
  • an empty answer with hints;
  • a short window starts no probe;
  • a failed probe.
  • RED: 9 of 11 failed against dev's tool code. GREEN: 11 of 11.
• The two PostgreSQL event tools, in a new live class, PgEventToolsWindowFloorLiveTests:
  • a start inside the window;
  • a quiet start;
  • an event older than the first collection;
  • a full capped page beside an early coverage reads covered while truncated is true;
  • a capped page beside a late coverage;
  • an empty answer with hints;
  • not_collected bare;
  • a short window;
  • a failed probe.
  • RED: 7 of 9 failed against dev's tool code. GREEN: 9 of 9.
• Rosters: the payload census and EffectiveStartUtcTests rows.
• On each branch:
  • --no-incremental build: 0 warnings;
  • every Darling.Tests class that names a changed file, against a live PostgreSQL store;
  • every class that reads repository source: every failure is one that fails only on macOS.

CHANGELOG

SECTION: Fixed
ENTRY: - Darling's blocking stats and PostgreSQL deadlock and log event MCP tools say where their data starts ([#5205]) - get_blocking_stats, get_pg_deadlocks and get_pg_log_events carry effective_start, window_truncated and truncation_note (under hints on an empty answer). get_blocking_stats names the later of its blocking and deadlock start points, so an uncovered deadlock half no longer reads as "no deadlocks"; the event lists name the earlier of the store's coverage and the oldest event shown.
REF: [#5205]: #5205

Part of #4966