Thread cancellation through 5 more web reads: 2 trends, 3 analysis (#4203)

[erikdarlingdata]

Refs #4203.

Why

get_file_io_trend, get_perfmon_trend, compare_analysis, get_analysis_facts and get_analysis_findings were still on the web endpoint's CancellationAllowlist, so an abandoned browser request to any of them kept running its store reads (and, for the three analysis tools, the inference engine's fact collection and scoring) to completion instead of stopping when the client gave up.

What changes

• get_file_io_trend, get_perfmon_trend (DarlingMcpTrendTools.cs): added a trailing CancellationToken cancellationToken = default, threaded to every store call (series/points/buckets, distinct-counter probe, has-any-stat probe, baseline discontinuities, server resolution, not-collected status), narrowed the catch to when (ex is not OperationCanceledException).
• compare_analysis, get_analysis_facts, get_analysis_findings (DarlingMcpTools.cs): same pattern. DarlingAnalysisService.CollectAndScoreFactsAsync and ComparePeriodsAsync gained an optional trailing cancellationToken that sets AnalysisContext.CancellationToken (both already had default-token store calls hung off that context, so nothing else needed to change downstream of ResolveEngineAsync). GetRecentFindingsAsync (service wrapper and PgFindingStore) gained the same optional parameter, threaded into the store's connection open / reader calls. DarlingForcePlanTargetStateReader.TryReadAsync already accepted cancellationToken; both findings-read call sites now pass it.
• DarlingWebEndpoints.cs: removed all 5 tools from CancellationAllowlist and updated their dispatch entries to pass cancellationToken: c.RequestAborted.

No other tool file touched. Two sibling #4203 slices are running on other branches and also edit the allowlist/dispatch table in this same file; the coordinator resolves that merge conflict.

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj -c Release -p:EnableWindowsTargeting=true — 0 errors, 2 warnings (pre-existing).
• dotnet build Lite.Tests/Lite.Tests.csproj -c Release -p:EnableWindowsTargeting=true — 0 errors, 0 warnings.
• WebReadCancellationPinTests run in-process on macOS (net10.0 host, WindowsDesktop framework entry stripped from the runtimeconfig): Total: 127, Errors: 0, Failed: 0, Skipped: 0. This suite is the reflection ratchet (EveryStoreReadingToolMethod_TakesACancellationToken_UnlessAllowlisted, CancellationAllowlist_HasNoStaleEntry) — leaving the allowlist makes it enforce these 5 tools going forward. RED case on the pre-fix code: any of the 5 dispatch entries still calling the tool method without cancellationToken: c.RequestAborted fails EveryStoreReadingToolMethod_TakesACancellationToken_UnlessAllowlisted (the entry is no longer allowlisted but its lambda drops the token), or, before this change, the tool methods themselves had no CancellationToken parameter to pass.
• Darling.Tests.dll / Lite.Tests.dll full Windows-targeted suites: not run here (net10.0-windows classes build but do not execute on macOS beyond the in-process runner used above); CI decides them.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Web reads honour request cancellation for 2 more trend charts and 3 analysis tools ([Thread cancellation through 5 more web reads: 2 trends, 3 analysis (#4203) #4411]) - get_file_io_trend, get_perfmon_trend, compare_analysis, get_analysis_facts and get_analysis_findings kept running their store reads (and, for the analysis tools, the inference engine's fact collection and scoring) to completion after a web request was abandoned. They now take a cancellation token and stop when the client disconnects.
  REF:
  [Thread cancellation through 5 more web reads: 2 trends, 3 analysis (#4203) #4411]: Thread cancellation through 5 more web reads: 2 trends, 3 analysis (#4203) #4411