Slack alerts in threads: add option to disable “Also send to #channel” (follow‑up to #94646)

### Problem Statement

Hi Sentry team — following up on the closed [#94646](https://github.com/getsentry/sentry/issues/94646). We couldn’t reply there after it was closed, but we have the same need and wanted to add concrete, configurable proposals.

### Problem
When issue alerts use Slack threads, all subsequent messages also post to the channel. This defeats the purpose of threads for teams that want to keep channel noise low and handle follow‑ups in the thread.

### Why an option makes sense
- You can mention users and user groups in a thread. Teams that prefer “thread‑only” can still reach the right people by tagging them in‑thread, without spamming the channel.
- Different teams have different Slack norms. This feels like a configuration choice rather than a one‑size‑fits‑all default.

### Proposed solutions
- Option: “Only post to thread (do not also post to channel)”
- Scope could be at the integration, project, or alert rule level.
- Default can remain current behavior to avoid breaking changes.
- Alt Option: Thread strategy on reopen (Resolved → Unresolved)
- Configure to start a new thread (or optionally posting a one‑time “resurfacing” message) so important state changes can be re‑surfaced without continuous channel noise.

### Benefits
- Less channel noise while preserving visibility via in‑thread mentions.
- Configurable to team preference, aligning with Slack usage patterns.
- Backwards compatible if the default remains “also send to channel.”

Happy to help test or provide more context on our workflow if useful. Thanks for considering!

References: [getsentry/sentry #94646](https://github.com/getsentry/sentry/issues/94646)

### Solution Brainstorm

_No response_

### Product Area

Alerts

Review closed issue #94646 first, then trace how Slack thread alerts are configured across the integration, project, and alert-rule scopes described here. Confirm the intended scope and thread strategy with maintainers; done means a configurable thread-only option works without changing the default channel-posting behavior, with reopen behavior explicitly decided.

Written by the indexing model from the issue text.