Clear the Windows build's warnings in the alert notebook endpoint, its tests, and the store upgrade's secret check

[erikdarlingdata]

Why

The release checklist calls for a Windows build with 0 Warning(s) / 0 Error(s), test projects included. Building Darling/Darling.Tests/Darling.Tests.csproj clean (--no-incremental, Release, -p:EnableWindowsTargeting=true) at the branch's starting point on dev reported 29 Warning(s) (a build run further back on dev had reported 25; dev had moved since then):

• 15 × CS8602 across four alert-notebook template test files (introduced by the Add authored-notebook context plumbing (#4223) #4425/Add the authored analysis-finding alert-notebook template (#4223) #4436-era test additions).
• 10 × CA1068 (CancellationToken not last) — 4 in AlertNotebookEndpoint.cs (introduced with Add authored-notebook context plumbing (#4223) #4425's PrefetchAsync/BuildCellsAsync extraction) and 1 in DarlingWebEndpoints.cs's RecordComposeLatency (introduced by Record web and composed-panel read durations into hourly latency histograms in the store (#4442) #4451/Add get_read_latency: p50/p95/p99 durations per web and MCP read, and name the web and MCP store connections (#4442) #4454's read-latency recording), each counted twice by the two build steps that touch this project.
• 1 × CS8604 in DarlingStoreUpgrade.cs:3413 (from Carry an operator's postgresql.conf lines below the include across a major upgrade (#4358) #4405, the operator-conf carry for Carry operator lines below the darling-managed.conf include across a major PostgreSQL upgrade #4358).
• xUnit analyzer warnings: 5 × xUnit2031 (already in the Windows build of run 36268957930), plus xUnit2000 and xUnit2013 in two files merged after that run.

PerformanceMonitor.Darling.Viewer and Lite.Tests both already build at 0 Warning(s) and are unchanged.

What changes

CS8602 (tests): each of the 15 sites called template!.Value.BuildCells(...) directly. BuildCells is a nullable delegate field on a readonly record struct, and the compiler can't narrow it through that member-access chain even after Assert.NotNull(template). Fixed by assigning the delegate to a local (var buildCells = template!.Value.BuildCells;), asserting that non-null, then invoking the local. Behavior-preserving; same delegate, same arguments.

CA1068 in AlertNotebookEndpoint.cs: BuildCellsAsync, both PrefetchAsync overloads, PrefetchCustomRuleAsync, and PrefetchAnalysisFindingAsync all had CancellationToken in the middle of their parameter list. Route-binding check: none of the four is a MapGet/MapPost lambda or anything the framework binds by reflection — BuildCellsAsync is an internal static method Map's handler calls directly (extracted for #4425 testability), and the three Prefetch* methods are its own internal helpers. Moved CancellationToken to the last parameter on all four and updated every call site: the endpoint's own call in Map's handler, the short PrefetchAsync overload's delegation to the long one, the internal switch in the long PrefetchAsync that calls the two PrefetchCustomRuleAsync/PrefetchAnalysisFindingAsync methods, and the test file's calls (all named-argument, so only the argument order needed to move). No endpoint route or public contract changed.

CA1068 in DarlingWebEndpoints.cs: RecordComposeLatency had the same issue. It's a private static helper called from one place inside the compose-run handler, not a bound delegate. Moved CancellationToken last and updated its one call site.

CS8604 in DarlingStoreUpgrade.cs:3413: NameMayHoldASecret(name) is called after var (_, name, _) = DarlingManagedPostgres.ParseConfText(rawLine).FirstOrDefault();, where name is string?. Reading the surrounding code: the very next check up above already tests name is not null (as part of isProbeableSetting) and continues past NameMayHoldASecret for any line where name is null (a comment, blank line, or include directive) — those lines never reach line 3413 at all. So null genuinely cannot reach NameMayHoldASecret; the compiler just couldn't see it through the two-variable isProbeableSetting boolean. Fixed by folding the null check directly into the guard's condition (if (name is null || s_confIncludeDirectiveNames.Contains(name, ...))) so the flow the type-checker follows is the same flow the code already had — no !, no behavior change, no new guard, no CHANGELOG-worthy effect.

xUnit analyzer warnings. The five xUnit2031 lines were already in the Windows build job of dev push run 36268957930. The other two files merged after that run, and the same analyzers flag them:

• ViewerFinOpsIntervalHonestLiveTests.cs (5 sites): xUnit2031 for Assert.Single(collection.Where(predicate)) → Assert.Single(collection, predicate).
• PairedClientDeadlinesTests.cs:68: xUnit2000 — swapped Assert.Equal(ceiling, McpCommandDeadlines.ComposedQueryFallbackSeconds) to Assert.Equal(McpCommandDeadlines.ComposedQueryFallbackSeconds, ceiling) so the constant is the expected argument. No bound or relation changed; this is the exact assertion Web viewer: stop sending exception text to the browser on the remaining paths (#4283) #4293/Web viewer: tool errors still show the exception text in the browser #4283 already pinned, just with its arguments in the order the analyzer wants.
• GetReadLatencyLiveTests.cs (2 sites): xUnit2013 — Assert.Equal(1, collection.Length) → var x = Assert.Single(collection), then asserting on x instead of collection[0].

No suppressions (#pragma warning disable, NoWarn, WarningsAsErrors) anywhere, and no new CI gate.

Updated source-text pins

None of the AlertNotebook* pins that assert call text or shape (the #4425 pins reaching BuildCellsAsync/PrefetchAsync through AlertNotebookAuthoredContextTests) broke — the reorder only moved a CancellationToken argument's position in named-argument calls, and the compiler enforced every non-test call site. No pin text changed in meaning; only the two BuildCellsAsync/PrefetchAsync call sites in AlertNotebookAuthoredContextTests.cs had their trailing ct:/positional-CancellationToken.None argument moved to match the new parameter order.

Test plan

RED (clean build at the branch's start, dotnet build Darling/Darling.Tests/Darling.Tests.csproj -c Release -p:EnableWindowsTargeting=true --no-incremental): 29 Warning(s) / 0 Error(s), unique lines: 15×CS8602 (the four template test files), 10×CA1068 (5 unique sites, each counted twice), 1×CS8604 (DarlingStoreUpgrade.cs:3413), plus the 4 unique xUnit warnings.

GREEN (same build, after the fix): 0 Warning(s) / 0 Error(s).
PerformanceMonitor.Darling.Viewer and Lite.Tests: 0 Warning(s) / 0 Error(s) both before and after (unchanged).

Mutation (proves the CA1068 pin is live, not tautological): moved CancellationToken back to the front of PrefetchCustomRuleAsync's parameter list (and its one call site) — rebuild reported exactly warning CA1068 at that line, 1 Warning(s). Reverted; rebuild returned to 0 Warning(s).

AlertNotebook* test classes run in-process (dotnet Darling.Tests.dll -class <name>, after stripping the Microsoft.WindowsDesktop.App framework reference from the runtimeconfig, on this Mac):

Class	Total
AlertNotebookAuthoredContextTests	26 (4 skipped, live-PG)
AlertNotebookAuthoredTemplateTests	152
AlertNotebookEndpointTests	29
AlertNotebookRenderClientTests	9
AlertNotebookReportsTests	8
AlertNotebookTemplateAnalysisFindingsTests	9
AlertNotebookTemplateCpuTests	3
AlertNotebookTemplateCustomRulesTests	11
AlertNotebookTemplatePoisonWaitTests	13
AlertNotebookTemplatePostgresTests	9
AlertNotebookTemplateQueryPlansTests	8
AlertNotebookTemplateSelfMonitorTests	22
AlertNotebookTemplateServerAgentTests	12

All 0 Errors, 0 Failed.

Also ran DocCommentHygieneTests (77, 0 Failed — required after touching doc comments/members) and DarlingStoreUpgradeTests (the class covering CarryOperatorConfLinesAsync, the caller of NameMayHoldASecret): 146 Total, 6 Failed, 13 Skipped. The 6 failures are pre-existing and unrelated: they assert literal Windows path strings (e.g. "C:\\Program Files\\Darling\\pg-runtime-prev") that fail on this Mac's /private/var/... paths — a macOS-vs-Windows path-format mismatch, not a regression from this change. Ran the two CarryOperatorConfLinesAsync_* tests individually (the ones that actually exercise the NameMayHoldASecret call site): both pass, 0 Failed.

Darling.Tests.dll, PerformanceMonitor.Darling.Viewer, and Lite.Tests all BUILD on macOS (target net10.0-windows) but the six Windows-path-specific DarlingStoreUpgradeTests failures and any WPF-touching test cannot run here; CI decides those.

Not run here: the 4 skipped AlertNotebookAuthoredContextTests facts need live PostgreSQL, so CI's PostgreSQL shards run them. The 6 DarlingStoreUpgradeTests failures on this Mac were not compared against a run on dev. They assert Windows path strings, so CI on Windows decides them.

How to check it

This PR's own Windows build job must read 0 Warning(s) in the Darling build step (dotnet build Darling/Darling.Tests/Darling.Tests.csproj -c Release --no-restore && dotnet build Darling/PerformanceMonitor.Darling.Viewer/...). That's the merge gate.

CHANGELOG entry

None: warning cleanup with no behavior change (the one product condition rewritten, in DarlingStoreUpgrade.cs, is logically identical).