Fix Poison Wait alert re-firing on an unrefreshed wait_stats row

[erikdarlingdata]

Fixes #2703.

Problem

`AlertEngine.CheckPoisonWaitsAsync` gates re-firing purely on wall-clock cooldown (`CooldownElapsed`). `IAlertReadAdapter.GetPoisonWaitDeltasAsync` always asks "what's the newest poison-wait `wait_stats` row within the last 10 minutes" (`ORDER BY collection_time DESC LIMIT 3`) — independent of whether that row is NEW since the last ask. When the collector's delivered cadence lags the alert cooldown (documented fleet behavior at load), the same still-unrefreshed row answers the question twice, and the engine fires again on data it already reported. Observed live: byte-identical `RESOURCE_SEMAPHORE_QUERY_COMPILE` alerts on the same server 6.5 minutes apart, same avg/delta/task values to the decimal.

This is unlike CPU's alert, which is correctly level-triggered (resampled live every sweep — an identical reading really is a fresh observation of a standing condition). A wait_stats delta is one collector cycle's computation; reading it twice is the same event, not two observations.

Fix

• `PoisonWaitDelta` gains `CollectionTime` (the row's own `collection_time`).
• Both read-adapter implementations (Darling/Postgres, Lite/DuckDB) select and populate it — one added column in an already-parameterized query, no behavior change to what rows are selected.
• `AlertEngine` tracks the collection_time it last actually fired on, per server, in a new `_lastPoisonWaitCollectionTime` dictionary (mirroring the existing per-family cooldown dictionaries). Re-fire now requires BOTH cooldown elapsed AND a newer collection_time than last fired — a cooldown-elapsed re-ask against unrefreshed data waits for the next sweep instead of re-firing.

Test plan

• `dotnet build` (full solution) clean, 0 errors
• New test `PoisonWait_DoesNotRefire_OnTheSameCollectionTime_EvenAfterCooldownElapses` in `AlertEngineTests.cs`: fires once, then asserts a cooldown-elapsed re-ask against the SAME collection_time does NOT re-fire, then asserts a genuinely new collection_time (same wait-type/value shape) DOES fire. Hand-traced against the new gating logic; Darling.Tests can't run on macOS (net10.0-windows) — relying on CI's `Darling PostgreSQL tests`/`build` jobs to actually execute it.
• Existing `PoisonWait_FiresWithWorstWaitNumerics_AndResolvesWhenGone` and Lite's `PoisonWait_ToastBody_UsesTheWorstWait` unaffected — both fire only once per test, so the new gate is a no-op on their paths (empty tracking dictionary on first fire).

🤖 Generated with Claude Code

[claude]

Reviewed. This is a clean, well-scoped fix.

Correctness: The gating logic is sound. triggered is already ordered by collection_time DESC (both adapters), so triggered.Max(w => w.CollectionTime) is consistent with whatever subset survives the post-fetch threshold filter — no mismatch between "worst" (triggered[0]) and "newest" in practice. The new dictionary is only stamped inside the same gate that fires the alert, mirroring the existing _lastPoisonWaitAlert[key] = now pattern.

Parity: AlertEngine is shared between Lite and Darling, so the core gating change only needed to land once. Both read adapters — DarlingAlertReadAdapter.PoisonWaitsSql (Postgres) and LocalDataService.GetLatestPoisonWaitAvgsAsync (DuckDB) — got the same collection_time column added at the same select-list position (ordinal 4), and both constructors populate it via reader.GetDateTime(4) with no IsDBNull guard, consistent with how collection_time is already handled elsewhere in DarlingAlertReadAdapter.cs (e.g. CurrentBlockingWaitSql). No drift.

Tests: PoisonWaits_ToastBody_UsesTheWorstWait (Lite) and PoisonWait_FiresWithWorstWaitNumerics_AndResolvesWhenGone (Darling) both fire only once per test, so CollectionTime defaulting to DateTime.MinValue on those un-updated PoisonWaitDelta literals is harmless — the new gate is a no-op on the first observation for any key (empty dictionary → hasFreshCollection = true). The new regression test correctly advances the clock past the 5-minute default cooldown before asserting no re-fire on the same collection_time, then advances again with a new collection_time to assert it does fire.

Minor, pre-existing, not introduced by this PR: triggered[0] is documented ("worst… highest avg ms/wait") but the query only orders by collection_time DESC, not by avg_ms_per_wait. So "worst" is really "most recently collected," not "worst by magnitude," whenever more than one wait type triggers in the same window. Out of scope here since the diff doesn't touch that ordering, just flagging for awareness.

No correctness, parity, security, or performance concerns that block this.