[Feature] Native threading support for Google Chat receiver

[celsodias12]

What

Native threading support for the Google Chat receiver: group resolved messages under the original firing message via the Google Chat thread.thread_key API.

Why

Firing and resolved notifications for the same incident are posted as disconnected top-level messages today, making it hard to follow an alert's lifecycle in busy channels.

Problem

The Google Chat receiver currently posts every alert notification as a new top-level message. There is no native way to group the resolved message under the original firing message, so a single incident produces 2+ disconnected messages in the channel. For high-traffic spaces, this drowns out the visual lifecycle of an alert and makes it harder for on-callers to see "this firing alert is now resolved" at a glance.

Google Chat's API supports threading via thread.thread_key + messageReplyOption=REPLY_MESSAGE_FALLBACK_TO_NEW_THREAD. The receiver could leverage it to keep firing → resolved messages in the same thread.

Use case

[Channel feed]
├─ 🔥 Alert X firing  (thread root)
│   └─ ✅ Alert X resolved  (reply, same thread)
├─ 🔥 Alert Y firing
│   └─ ✅ Alert Y resolved

vs. today:

🔥 Alert X firing
🔥 Alert Y firing
✅ Alert X resolved
✅ Alert Y resolved

Desired behavior

• The feature is opt-in (some teams may prefer the current flat layout).
• Firing and resolved notifications belonging to the same incident land in the same thread.
• A fresh incident — i.e. firing again after a previous resolution — starts a new thread instead of extending the previous one indefinitely. The exact notion of "incident identity" is open for discussion.
• No regression for users who do not enable the feature.

Open questions

These are intentionally left open for the maintainers and the community to weigh in:

1. How should a "new incident" be identified so that firing → resolved → firing-again creates a new thread? Several approaches are conceivable (contextual data on the alert group, a persistent state store, etc.) — each has different trade-offs around HA, persistence, and complexity.

Contribution

I'm available to implement this if the maintainers are open to the proposal. Happy to align on the design direction before any code is written.