Add channel routing for error notifications (Slack, Discord)

[Mr-DooSun]

Problem

The base error-notification feature (#17) sends Slack/Discord webhooks on
qualifying exceptions, but routes everything to a single configured target.
Teams usually want severity-based fan-out so noisy warnings and true incidents
don't land in the same channel.

Proposed Solution

Build on top of the notification infra from #17:

• Route by severity, e.g. critical → #alerts, warnings → #monitoring
• Configurable mapping via settings/env (keep the single-target default when unset)
• Reuse the existing Protocol + Selector adapters and the severity threshold
  already introduced in Add error notification (Slack, Discord) #17 — this is routing on top, not a new transport

Notes

• Deferred from Add error notification (Slack, Discord) #17 to keep the base notification PR focused.
• No new domain/table expected; likely just settings + a small routing layer
  in front of the existing webhook adapter(s).

Area

Core (_core)

[siddhanttiwari19]

Hi @Mr-DooSun, I'd like to work on this. My understanding: build a routing layer on top of the existing webhook adapters from #17, keyed by severity, critical to one channel and warnings to another, configurable via settings/env with the current single target as default when unset. I'd reuse the existing Protocol and Selector adapters rather than add a new transport. Before starting, should the severity to channel mapping live in the same settings model as #17, or a separate nested config? I'll open a draft PR once confirmed.

[Mr-DooSun]

Thanks for the interest and for laying out the plan so clearly, @siddhanttiwari19 — your understanding is spot on. Reusing the existing Protocol + Selector adapters as a routing layer on top (rather than a new transport), with the single-target default preserved, is exactly the intended shape.

One sequencing issue, though: #286 was deliberately split off from #17 as a follow-up, and it builds directly on the base notification infra from #17 — the webhook adapters and severity threshold you'd be routing on top of. That base work is currently assigned and in progress (#17), but it hasn't landed yet, so there's nothing in the codebase to build on for now. Starting #286 before #17 merges would mean building against an interface that doesn't exist and may still shift.

So I'd rather hold this one until #17 is merged. I'll ping you right here as soon as it lands — your approach is the right one, and I'd be glad to have you pick this up then. (We can settle the settings-shape question — shared model vs. separate nested config — at that point, once #17's final shape is locked in.)

Appreciate your patience, and thanks again for the thoughtful write-up!