Lite's get_query_trend carries the same source/effective_start/truncated block its Darling twin has had since #2353, so the last cross-SKU envelope mismatch in the trend family closes (#3541 A2 follow-up)

[erikdarlingdata]

Lite's get_query_trend carries the disclosure block its Darling twin has had since #2353

#3590 gave the duration-trend trio one six-key disclosure block — source, effective_start, effective_hours_back, truncated, bucket, aggregate_note — on both SKUs. The bot review of that PR pointed at the one tool left where the SKUs' envelopes still disagreed: Darling's get_query_trend has published the block since #2353, Lite's returned the bare {server, database_name, query_hash, hours_back, data_points, trend}. This is that fix, taken in-lane rather than filed. It was pushed to #3590's branch as its fifth commit, but auto-merge fired on the fourth commit's green checks a minute earlier, so it rides here on its own.

What changes

Lite McpQueryTools.GetQueryTrend's DATA envelope writes the same block between hours_back and data_points, through the WriteDisclosure helper #3590 added one screen up: source always raw (Lite has one tier), bucket per-collection, effective_start the first point the store held, truncated by the shared 90-minute slack. Its empty branch stays a bare status, exactly like Darling's get_query_trend empty branch, so the twins now match on both paths. The Lite instructions row says so.

What it does NOT do

Nothing on Darling; nothing to any reader. No CHANGELOG entry of its own — it belongs under #3590's entry (partial #3541, A2).

Test plan

Compile-verified here (Lite + Lite.Tests, zero warnings); first executed in CI. TrendEmptyParityToolTests.QueryDurationTrend_NeverCollected_AndAQuietWindow_AreDifferentAnswers now also reads get_query_trend over the same seeded query and asserts source, bucket, effective_start = the first point's collection_time, truncated (a series beginning ten minutes ago in a four-hour window starts past the slack) and data_points.

Which component(s) does this affect?

• Lite
• Darling
• Lite Tests
• Darling Tests
• SQL collection scripts
• Documentation
• Full Dashboard (deprecated)
• CLI Installer (deprecated)

How was this tested?

Compile-verified on Lite and Lite.Tests with zero warnings; the assertion above is the same shape the sibling tools' assertions in the same file already use over the same DuckDB fixture.

Checklist

• I have read the contributing guide
• My code builds with zero warnings (dotnet build -c Debug)
• I have tested my changes against at least one SQL Server version
• I have not introduced any hardcoded credentials or server names

[claude]

LGTM — verified the disclosure block wiring in McpQueryTools.GetQueryTrend matches Darling's field order/semantics (source, effective_start, effective_hours_back, truncated, bucket, aggregate_note), confirmed the empty branch correctly stays bare (matching Darling's empty branch), checked rows[0] is safe since the empty-count path returns early, verified rows are ordered ascending by collection_time so effective_start is computed from the true first point, and confirmed the new test's truncation assertion is consistent with TruncationSlack. No other Lite call sites needed updating (McpAnalysisTools/McpInstructions only reference the tool name in text). No Darling changes needed since Darling already had this block since #2353.