MCP: Darling's blocking, deadlock and long query tools say where their data starts (part of #4966)

[erikdarlingdata]

What an MCP client sees

get_blocking, get_deadlocks, get_deadlock_detail, get_blocked_process_xml and get_long_query_completions now write effective_start, window_truncated and truncation_note right after hours_back, the same three keys and wording Darling's other data-start tools use. An empty answer carries them under hints. If the coverage probe fails, the rows still come back, without the keys (and an empty answer without hints). A window of 90 minutes or less that returns rows starts no probe.

The event-time rule

These are event lists: a collector's first run can store events stamped before itself. The start named is the earlier of the probe's answer and the oldest event the page shows, so a notice never names a start later than a row on the same page. A backfilled event gives no notice.

Coverage source per tool

All five use DataWindowFloor.Source.ForCollectorTable:

• get_deadlocks, get_deadlock_detail: deadlocks.
• get_blocked_process_xml: blocked_process_reports only (the XML exists only there).
• get_blocking: both blocked_process_reports and dmv_blocking_snapshots, the earliest winning, because its page merges both sources.
• get_long_query_completions: long_query_completions.

A blocked process report collector turned on after the server was registered reads as covered from the registration, as in every other Darling coverage note.

Test plan

• RED: tests committed first; DarlingMcpBlockingToolsLivePostgresTests Total: 9, Failed: 6 (the other 3 cases were already green).
• GREEN after the code: same class Total: 9, Failed: 0 (cases: notice inside window, quiet start, backfill, empty past coverage with hints, key order, short window starts no probe, capped page, failed probe; six tools/shapes each, with get_blocking covered on both its XE-only and both-source probes).
• McpToolsListBudgetTests 5/0, McpPayloadContractCensusTests 68/0 (rosters updated), EffectiveStartUtcTests 14/0, McpPageContractTests 43/0.
• Build --no-incremental: 0 warnings.
• Guard family: Total: 956, Failed: 1 (LivePostgresCollectionHygieneTests, the allowed one).

On the web page

None of these five reads is in the web note's own list, so the web server page's Blocking, Deadlocks, Deadlock Graphs, Blocked Process Reports and Long Query Completions grids now show the tool's own note above the grid when its window was cut, the way the Top Queries, Active Queries and Query Heatmap grids already do. No page code changed.

Review fixes, at fa396eb7c

• get_blocking always probes both the blocked process report and the DMV blocking snapshot coverage, the earlier winning, because its page merges both sources; get_blocked_process_xml stays on the reports alone.
• The backfill case now stores its event at a collection time after the server's registration, with the event time far earlier, and fails with the event-time rule removed.
• Response budgets at the default call, against 32,768 bytes: get_blocking 27,129 (its budget class), get_deadlock_detail 22,839; in the read-tool budget class get_blocking 19,436, get_long_query_completions 17,809, get_deadlock_detail 17,763, get_blocked_process_xml 13,489, get_deadlocks 7,130. All pass.
• Totals: DarlingMcpBlockingToolsLivePostgresTests 9, the three budget classes, the census (68), the formatter pins (14) and the page contract (43), all 0 failed; the guard family 956 with its one allowed WPF-only failure.

CHANGELOG

SECTION: Fixed
ENTRY: - Darling's blocking, deadlock and long query tools say where their data starts ([#5171]) - get_blocking, get_deadlocks, get_deadlock_detail, get_blocked_process_xml and get_long_query_completions now report effective_start, window_truncated and truncation_note, so an empty or short answer over a window the store does not reach back to is no longer read as nothing happened.
REF: [#5171]: #5171

Part of #4966