Add exact module filtering to Query Store MCP results

[kendra-little]

Problem

Query Store results are ranked globally, so callers cannot reliably investigate a specific stored-procedure module when its queries fall outside the top results. The response also omits the module attribution already present in collected data.

Value

Callers can retrieve exact module-scoped Query Store history without increasing broad result limits, while retaining query and plan identity for follow-up analysis.

Summary

• add an optional exact module-name filter to the Query Store MCP read
• deduplicate cumulative interval snapshots before applying the filter
• apply the filter before cost ranking and result limits
• return module attribution with each result
• keep the existing inexpensive, unfiltered retention-floor probe
• preserve existing unfiltered behavior across the Lite and Darling surfaces

Validation

• focused Query Store read and interval-dedup regression coverage
• Darling and Lite MCP contract coverage
• Darling and Lite test-project builds
• public disclosure scan over code, history, branch, commit text, and this PR text

CHANGELOG entry

• get_query_store_top takes module_name, so one stored procedure's Query Store history can be read without widening top ([Add exact module filtering to Query Store MCP results #4057], contributed by @kendra-little) - the read ranked the whole window before capping it, so a procedure an investigation named but whose queries sat outside the top N could not be reached at all. The filter is part of the query on both SKUs. It matches the exact, case-sensitive, schema-qualified name the collector records (the full_name get_top_procedures_by_cpu returns, Adhoc for ad-hoc statements), and it applies after the Query Store aggregates double-count re-collected cumulative intervals - tier 2: interval identity + CAGG rebuild (tier 1 read-side dedup shipped in #1845) #1841 interval dedup and before the ranking and the cap. Every row now carries module_name, beside the execution_type Expose Query Store execution outcomes in MCP results #4060 added, and the two filters compose. A filter that matches nothing answers empty only when the same read without the filters has rows, and the message names both filters; on Darling a module miss also carries effective_start, effective_hours_back and window_truncated as hints. Otherwise the read answers as an unfiltered one would.

[erikdarlingdata]

Thanks for this. The filter is in the right place on both SKUs: after the interval dedup and before the ranking and the cap. A live check against PostgreSQL returned a cooler target at top = 1, with its re-collected interval counted once.

I pushed two commits to this branch (0739144d5, 777cd9801), so please pull before pushing again.

• A miss is empty only when there was something to miss. A module_name filter that matched nothing answered empty, the house word for a true negative, even when the window held no Query Store rows at all. In that case the filter isn't the reason, and the unfiltered read answers unavailable. The Darling message also pointed at effective_start, which the status envelope didn't carry.
  • Darling now decides on the window floor it already probes, and the miss carries effective_start, effective_hours_back and window_truncated as hints.
  • Lite asks a window-scoped HasQueryStoreRowsInWindowAsync, only on the miss.
• A live Darling pin in McpFilterSemanticsLivePostgresTests, beside the parallel_only one it follows. It covers the rank at top = 1, the dedup, the miss's hints, and the empty-window answer. It goes red with the old condition.
• The tools/list budget. The heads went back to dev's text, plus "Supports database and module filtering." The guidance moved into a shorter parameter description (the name as get_top_procedures_by_cpu returns it in full_name, with Adhoc for ad-hoc statements). The new parameter is pinned and the totals are raised with a change-log line on both SKUs. McpToolsListBudgetTests would otherwise have failed on both.
• Doc comments. The floor probe's doc no longer says "filtered", and QueryStoreTopSql names $5 and $6.
• Changelog. A ## CHANGELOG entry is added to the description; the release changelog is built from those.

[erikdarlingdata]

Merged current dev into the branch and fixed two CI failures. The branch is now at a90b0b27f, so please pull before pushing again.

• Conflicts. get_collection_log and get_query_store_top reading guides move off tools/list (#3898) #4065 had moved get_query_store_top to a two-tier description (The MCP surface costs ~100k tokens of context before the first call: 157 tools, 336 KB of tools/list, 86 KB of instructions #3898). The head is dev's, unchanged. The module_name rules and how a miss answers now sit in the tail that get_tool_guide serves. That makes my earlier note out of date: after dev's conversions, neither SKU's tools/list total needs raising. The only budget change left is the module_name parameter's pin line.
• AsOfWindowAnchorTests. The Lite miss probe now takes asOfUtc: by name, as the census requires of every anchored read.
• ConsumedTimestampFrameDisciplineTests (judged render sites fell from 43 to 40). The probe had been placed in LocalDataService.QueryStats.cs, so that file now appeared to read v_query_store_stats. That left three timestamp columns shared across the two tables unresolved. The probe now lives in LocalDataService.QueryStore.cs beside the other Query Store reads, and QueryStats.cs is back to dev. A bisect confirmed that one file was the cause.

The full Darling suite ran against live PostgreSQL at dev and at the merged head. The only difference is that render census, which this push fixes.

[erikdarlingdata]

dev moved again, and #4060 (your execution_type filter) had landed on the same read, so I merged dev in and combined the two filters. The branch is now at 1e939b7af.

• SQL: execution_type stays $6, in the dedup CTE where Expose Query Store execution outcomes in MCP results #4060 put it. module_name is $7, after the dedup and before the ranking. Rows carry both fields. Lite binds the outcome, then the module, after the database list, and a new Lite test covers all three together.
• Parameters: …, as_of, execution_type, module_name on both SKUs.
• A filtered miss: it now uses Expose Query Store execution outcomes in MCP results #4060's test for both filters, the same read without the filters scoped to the database, instead of this PR's server-wide window check. Lite's HasQueryStoreRowsInWindowAsync is gone. An execution_type-only miss keeps your message word for word. A miss with module_name goes through a new shared McpHelpers.QueryStoreModuleEmpty, which names both filters and, on Darling, still carries the window read as hints.

The full Darling suite against live PostgreSQL fails exactly the same tests at dev and at this head. Auto-merge is armed on this commit.