[BUG] A webhook batch posts when ANY incident is outside its #1154 cooldown, then re-renders EVERY incident on the card - already-delivered signatures repeat in Slack #3313

Summary

WebhookAlertService.PostAsync asks IncidentCooldown.EvaluateAsync whether to post, and that call is documented as "Post if any incident in this alert is outside its window (a distinct fingerprint is not throttled by an unrelated prior incident)". That half is correct and is what #1154 built.

The problem is what gets rendered once the decision is ShouldSend. The channel builders render every incident in context.Incidents, including the ones that are still inside their own cooldown window and were already delivered minutes earlier. A single new fingerprint therefore drags every co-resident stale fingerprint back into the channel with it.

So the per-fingerprint cooldown governs whether a card posts, but nothing governs which incidents that card contains. Raising the cooldown does not fix this, because the repeat is not a second firing of the old fingerprint — it is a passenger on the new one's card.

Observed

A 74-minute window on a 42-server SQL Server store delivered 18 Deadlocks Detected cards. Three of them re-delivered a fingerprint that had already been posted inside the same window.

The clearest instance, one server, Summary mode:

Total Occurrences: 1 on the second rendering is the proof that this is a re-render and not a recurrence: the occurrence accumulator (#2216) saw no new events for that fingerprint between the two cards. The incident was simply still in the rolling 1-hour read window, so it rode along.

Expected

When a batch posts, render only the incidents that are actually outside their own cooldown window — the same set IncidentCooldown stamps on success. An incident inside its window has already been delivered and should be omitted from the card, not repeated.

If dropping it entirely loses useful context, a one-line "N other incidents still open (already reported)" footer preserves the signal without restating each one.

Notes

• IncidentCooldown.EvaluateAsync already computes the per-fingerprint decision set, so the information needed to filter the render is present at the decision point and does not need to be recomputed.
• The same path serves Teams, Slack, PagerDuty and the generic webhook, so the fix is one place for all four.
• Lite shares PerformanceMonitor.Notifications, so it has the same behavior.
• Interaction with AlertNotificationMode.PerEvent ([FEATURE] Add a "per‑event" notification option (vs. the batched per‑cycle summary) for deadlocks & blocking #1141): PerEventNotification.Split emits one message per incident, and each goes through SendAndRecordAsync separately — but the cooldown is evaluated once per PostAsync call over the whole incident set, so the split messages need the same filtering applied before the split, not after.