feat: add provider capability declaration system

[Moh-dakai]

Summary

Introduces a capability-aware notification provider abstraction so providers can declare what features they support, unsupported features are handled gracefully, and the core notification pipeline never depends on a concrete
provider class.

Motivation

The pipeline previously had a hard-coded switch statement in NotificationScheduler.executeNotification that directly instantiated Discord-specific logic and threw not yet implemented errors for every other channel. This made it
impossible to add new providers without modifying the scheduler, and gave callers no way to know whether a feature like rich formatting or file attachments was available before attempting delivery.

Changes

New types — src/types/provider-capabilities.ts

• ProviderCapability enum with six values: RICH_FORMATTING, ATTACHMENTS, MESSAGE_UPDATES, THREADING, INTERACTIVE_COMPONENTS, NATIVE_SCHEDULING
• ProviderMetadata — id, name, version, and a ReadonlySet
• DeliveryPayload / DeliveryResult — strongly-typed input/output for every provider
• NotificationProvider interface — the only type the pipeline imports; no concrete classes

Discord provider — src/services/providers/discord-provider.ts

• Wraps the existing DiscordNotificationService behind NotificationProvider
• Declares 5 capabilities (RICH_FORMATTING, ATTACHMENTS, MESSAGE_UPDATES, THREADING, INTERACTIVE_COMPONENTS)
• Any requested feature not in that set is logged and listed in DeliveryResult.degradedCapabilities; delivery still proceeds

Webhook provider — src/services/providers/webhook-provider.ts

• Generic HTTP POST provider; declares only ATTACHMENTS
• All other requested features degrade gracefully

Provider registry — src/services/provider-registry.ts

• ProviderRegistry class: register, unregister, get, has, listIds, findByCapability, deliver
• Module-level singleton helpers: getProviderRegistry / setProviderRegistry / resetProviderRegistry for easy test isolation
• deliver() returns success: false with a clear error message instead of throwing when no provider is registered for a type

Scheduler update — src/services/notification-scheduler.ts

• Injects ProviderRegistry (defaults to the module singleton, overridable in tests)
• executeNotification queries the registry first; falls back to the existing direct-Discord path so existing deployments without a bootstrapped registry continue to work
• Added missing verifyPayloadIntegrity import (was called but never imported)

Tests — src/services/providers/provider-capabilities.test.ts

35 tests covering:

• ProviderCapability enum shape
• hasCapability true/false for declared vs undeclared features
• Discord provider: capability declarations, successful delivery, 4xx/network failure, graceful degradation
• Webhook provider: same matrix
• Registry: register, overwrite, unregister, findByCapability, dispatch to correct provider, unknown-provider error
• Singleton helpers: isolation between test runs
• Pipeline independence: an ad-hoc provider object satisfies the contract; providers can be swapped without changing the call site

Acceptance criteria

┌──────────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Criterion │ How it is satisfied │
├──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Providers can declare supported capabilities │ ProviderMetadata.capabilities: ReadonlySet + hasCapability() │
├──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Unsupported features are handled gracefully │ deliver() populates DeliveryResult.degradedCapabilities and logs a warning; delivery still succeeds │
├──────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ The core pipeline does not depend on a specific provider │ NotificationScheduler only imports ProviderRegistry and the NotificationProvider interface │
└──────────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────┘

Testing

35 tests, 35 passed

Closes #708

[drips-wave]

@Moh-dakai Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits