MCP: Darling's four data-start twins, and Lite's config change, collection log, plan correction and memory pressure tools, say where their data starts (part of #4966)

[erikdarlingdata]

This PR also carries the Darling MCP twins (first reviewed as #5131), which edit the same test rosters and so can't land in a separate train. #5131's own description, reviews and test record apply unchanged. In short: Darling's get_active_queries, get_waiting_tasks, get_query_heatmap and get_query_store_regressions now carry the same three data-start keys, through a shared helper, with a failed coverage probe costing the notice and never the rows; get_active_queries writes them only when the window was cut, and its query-text preview is 400 characters in both apps so a cut window stays inside the response budget.

Lite's get_server_config_changes, get_database_config_changes, get_trace_flag_changes, get_collection_log (one-server form), get_plan_corrections and get_memory_pressure_events now say where their data starts. They use the same contract as the other Lite window-floor tools (#5004, #5015, #5127). This is the second Lite group of #4966.

What an MCP client sees

• A data answer carries effective_start (UTC, with a Z), window_truncated and truncation_note right after hours_back. They are always present: false and null when the store covered the window.
• An empty answer carries the same three keys under hints. An empty answer is always probed, whatever the window's length. If the store holds no collection of the window, effective_start is null, window_truncated is true, and the note says the empty answer is not a report that nothing happened.
• A data answer over a window of 90 minutes or less starts no probe and is covered at the asked start.
• not_collected and unavailable stay bare. So do the engine-capability answers. No tool description changed.
• No effective_hours_back. get_collection_log and get_plan_corrections carry a page truncated, and the census holds that key apart from the window floor.

Which tools use the event-time rule

None of the six do. EventWindowNoticeAsync is for a list where a first run can store rows older than itself AND the probe reads a different column from the row time. Neither holds here:

Tool	Relation and probe column	Why the plain notice
the three config tools	ServerConfig, DatabaseConfig, TraceFlags, on capture_time	A change is stamped with the capture time of the snapshot that showed it. The probe reads that column.
get_collection_log	CollectionLog, on collection_time	The rows are the run log. A run is stamped with its own time.
get_plan_corrections	PlanCorrection, on collection_time	Rows are per-run re-captures stamped with the run's time. The read and the probe use the same column.
get_memory_pressure_events	MemoryPressureEvents, on sample_time	The list is windowed on sample_time, the ring-buffer event's own time. The probe reads that column beside the collector's runs, so a backfilled event already lowers the floor. One test pins this.

Each probe reads the same source its read returns rows from.

The config tools needed one extra step. Their read keeps the snapshot before the window as the diff baseline, and the collectors capture on connect. So a server that stayed connected holds its last snapshot days before the window and none inside it. The plain probe finds nothing in the window and would tell an empty answer "the store holds no collection of this". That would be false. LocalDataService.GetConfigSnapshotCoverageFloorAsync also counts a snapshot before the window's start and answers the start. Without a snapshot before the window it answers what GetQueryWindowFloorAsync answers.

The collection log fleet form

server_name omitted or "*" carries no notice. It merges every enabled server's runs and names no server, so there is no single start to give. A code comment on GetCollectionLogFleetAsync and on the one-server branch says so, and a test pins that the fleet answer has none of the three keys.

For the one-server form the probe reads the run log itself and ignores the collector_name, min_duration_ms and status filters. The note says where the log starts, not where one collector's or one status's runs do. A filter that matches nothing still carries the log's start under hints.

Test plan

• Mac, Lite.Tests: --no-incremental build, 0 warnings, 0 errors.
• Mac, Darling classes: EffectiveStartUtcTests and McpPayloadContractCensusTests: Total 78, Failed 0.
  • Both census rosters (window_truncated, truncation_note) gain the four touched files.
  • A new EffectiveStartUtcTests pin covers them: each effective_start write comes from notice.EffectiveStart, the AsHints counts match, and none uses the event-time form.
• Windows VM, one run: McpWindowNoticeConfigAndLogToolTests (new), McpWindowNoticeEventToolTests and McpWindowNoticeToolTests: Total 142, Failed 0. No rerun was needed.
• New class, per tool:
  • a notice when collection starts inside the window;
  • none on a quiet start;
  • key order right after hours_back;
  • a short window starts no probe;
  • a limit: 1 capped page, for the two tools that page;
  • empty past coverage carries hints; empty with nothing held says nothing was read; empty with the collector covered says covered (the three config tools have their own cases).
  • Extra cases: a config window with only a pre-window snapshot, the memory pressure backfill, a plan-correction answer holding only the automatic-tuning snapshot, a collection log filter that matches nothing, a never-collected server (unavailable, bare), and the fleet form.
  • Every anchor uses a fixed as_of.
• RED: by construction, not run. Removing the key writes fails the key-order, notice and hints families. Removing the pre-window snapshot arm fails the config-window case.
• Full suite: CI runs it at ready time.

Review fixes, at 5936e803a:

• A config snapshot from before the window counts as coverage only when the server was monitored during the window (at least one collection-log run). With no run, the answer says nothing was read (AConfigWindow_OneSnapshotBeforeIt_ButNoRunInIt_SaysNothingWasRead, for all three config tools).
• The one-server collection log treats a status filter as a filter (CollectionLog_AStatusFilterThatMatchesNothing_TakesTheFilteredEmptyBranch).
• A one-hour automatic-tuning-only plan-corrections answer names the probe's floor (PlanCorrections_AOneHourTuningOnlyAnswer_NamesTheProbesFloor_NotTheAskedStart).
• On Windows, the three Lite window-notice classes: 147 tests, 0 failed. On the Mac, the census and formatter pins: 78, 0 failed.

CHANGELOG

SECTION: Fixed
ENTRY: - Lite's config change, collection log, plan correction and memory pressure MCP tools say where their data starts ([#5147]) - get_server_config_changes, get_database_config_changes, get_trace_flag_changes, get_collection_log (one server), get_plan_corrections and get_memory_pressure_events now carry effective_start, window_truncated and truncation_note, and an empty answer carries them under hints, so an empty answer over a window the store does not reach back to no longer reads as "nothing happened" (part of #4966).
ENTRY: - Darling's active queries, waiting tasks, query heatmap and Query Store regressions say where their data starts ([#5147]) - These four MCP tools now write effective_start, window_truncated and truncation_note, and carry them under hints on an empty answer, so an empty or short answer no longer reads as a quiet server when the store does not reach back to the start of the window. In both apps, get_active_queries now previews query text at 400 characters instead of 500, to keep a cut window inside the response budget; full_text: true still returns the whole text.
REF: [#5147]: #5147

Part of #4966