feat(cdk): wire DLQ CloudWatch alarms to SNS topic for alerting

[nizar-lahlali]

Context

PR #208 added CloudWatch alarms on FanOutDlq and ApprovalMetricsPublisherDlq (threshold: ApproximateNumberOfMessagesVisible >= 1, 5-min window). The alarms are exposed as public readonly dlqAlarm on each construct but are not yet wired to any notification channel — they fire silently in the CloudWatch console.

Proposal

Create an SNS topic (or accept one as a construct prop) and add alarm actions so operators get notified (email, PagerDuty, Slack webhook, etc.) when poison-pill records land in a DLQ.

Acceptance criteria

• An SNS topic is created (or injected via prop) for DLQ alarm notifications
• Both FanOutConsumer.dlqAlarm and ApprovalMetricsPublisherConsumer.dlqAlarm have an alarm action targeting the topic
• Optional: OK action to notify when the alarm returns to normal
• Unit tests verify the alarm action is wired to the SNS topic ARN
• cdk synth produces the expected AWS::CloudWatch::Alarm → AWS::SNS::Topic relationship

Design considerations

• Should the topic be shared across all DLQ alarms or per-construct? A single shared OperationalAlarmsTopic is simpler and matches the common pattern.
• Subscription management (email endpoints, chatbot integrations) can be handled out-of-band or via a notificationEndpoints stack parameter.

References

• Add CloudWatch alarms for FanOutConsumer + ApprovalMetricsPublisher DLQs #117 (original DLQ alarm request)
• PR feat(cdk): add CloudWatch alarms for FanOut + ApprovalMetricsPublisher DLQs #208 (alarm implementation without SNS)