ref(np): Dispatch provider renderers through a registry

[hobzcalvin]

Stacked on #112890 (gv/add_msteams_issue_renderer).

Summary

Each provider was hand-rolling the same category → renderer dispatch table inside its own get_renderer override. This replaces those with a NotificationRendererRegistry keyed by (provider_key, category).

• Renderers register themselves where they are defined, e.g. @renderer_registry.register(NotificationProviderKey.SLACK, NotificationCategory.ISSUE).
• NotificationProvider.get_renderer is now a single base implementation: look the pair up, fall back to default_renderer. The Slack, Discord, and MS Teams overrides are gone, and with them the function-local renderer imports they needed to dodge the renderer → provider circular import.
• get_renderer takes only the notification data now; the category comes from the notification's registered template rather than the call site.
• Dropped provider_key from the NotificationRenderer protocol — nothing read it.

Renderer modules are imported in sentry/notifications/apps.py alongside the providers so registration happens at startup.

Notes for review

• get_renderer is kept as the override seam rather than having callers hit the registry directly; it is public API used by the notification debugger endpoint and a number of tests, and it is the one place the registry's Any is narrowed back to the provider's renderable type.
• Dispatch is still keyed on NotificationCategory, which stays coarser than the data. SeerSlackRenderer covers seven sources and still branches internally on the data type. Keying on NotificationSource would let those split apart, but that is a larger change and not attempted here.

Test plan

• pytest tests/sentry/notifications/platform/ tests/sentry/integrations/slack/test_integration.py — 189 passing.
• Verified from a clean app startup that all six renderers register: Discord issue and metric alert, MS Teams issue, and Slack issue, metric alert, and Seer.

Made with Cursor

[sentry-warden]

SLACK_STAGING never resolves registered Slack renderers

get_renderer looks up by cls.key, but specialized Slack renderers only register under NotificationProviderKey.SLACK, so SlackStagingNotificationProvider always falls back to the default renderer for issue/metric/seer sources. Register those renderers for SLACK_STAGING as well, or fall back to the SLACK key when cls.key is staging.

Evidence

• get_renderer calls renderer_registry.get(provider_key=cls.key, source=data.source) and returns cls.default_renderer when that miss returns None.
• SlackStagingNotificationProvider sets key = NotificationProviderKey.SLACK_STAGING and inherits this base get_renderer.
• All Slack specialized renderers register only under NotificationProviderKey.SLACK (issue, metric_alert, seer, seer_agent_write_approval).
• Prior category-based Slack overrides were inherited by staging and returned the specialized renderers; source+provider_key lookup no longer does.

_{Identified by Warden · sentry-backend-bugs · R99-8QC}