Slack text cuts land on UTF-16 indexes at four sites: a surrogate pair astride a limit yields an invalid payload — the invalid_attachments outcome through a different door #3622

Summary

WebhookAlertService now cuts Slack text at four fixed character positions — the #3493 prose fragment cut and hard split, and #3618's SlackFieldText (2,000) and SlackHeading — all by UTF-16 index. A cut that lands between the two halves of a surrogate pair (any emoji or supplementary-plane character in a query text, database name, or advice string) produces an unpaired surrogate, which JsonSerializer escapes as a lone \uD83D-style unit and Slack rejects the whole payload as invalid — the same invalid_attachments outcome #3493 and #3618 were built to end, arriving through a different door, exactly once, on whichever page happens to carry an emoji at the boundary.

Fix

One helper — trim to the nearest char boundary (char.IsHighSurrogate(text[cut - 1]) → back off one) — applied at all four sites, with a pin that places a surrogate pair astride each limit and asserts the payload round-trips as valid UTF-16 and the omission count is stated in characters the reader would count. Also worth deciding: cut on the grapheme (StringInfo) rather than the code point, so a combining sequence isn't split either; cheap, and it makes the omission counts honest for the text the reader sees.

Found by #3618's review (non-blocking note; two of the four sites predate that PR, so it was left for a follow-up rather than folded). Related: #3493, #3612.