Feat/cooldown mechanism

[busehalis-sap]

Summary

Adds an optional cooldown mechanism to prevent sending the same notification type to the same recipient with the same target parameters too frequently.

When cooldown: <days> is set on a @notification-annotated event, the plugin checks the notification history before sending. If a notification of the same type was already sent to the same recipient with the same target parameters within the cooldown window, the notification is skipped. If only some recipients are in cooldown, the notification is still sent to the remaining recipients.

Requires cds.notifications.storeNotifications: true.

Changes

• CooldownChecker — new class that queries the notification history and filters out recipients within the cooldown window
• ProductionHandler / LocalHandler — cooldown check applied before sending/logging each notification
• NotificationServiceConfiguration — CooldownChecker is instantiated and passed to handlers when storeNotifications is enabled
• notificationtypes-data.cds — added ReminderNotification event for integration tests
• CooldownCheckerTest — unit tests for cooldown logic
• CooldownIntegrationTest — integration tests covering all cooldown scenarios
• sample-app/notifications.cds — cooldown example on LowStockAlert
• README.md / CHANGELOG.md — cooldown mechanism documented