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

## 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

- #117 (original DLQ alarm request)
- PR #208 (alarm implementation without SNS)

Inizia leggendo la PR #208 e le definizioni di FanOutConsumer e ApprovalMetricsPublisherConsumer, concentrandoti sulle loro proprietà pubbliche dlqAlarm. Determina se il topic SNS per le notifiche è condiviso o iniettato, quindi esamina i pattern esistenti per gli unit test e la sintesi CDK. Il lavoro è completato quando entrambi gli allarmi hanno azioni SNS, i test verificano l’ARN del topic e cdk synth mostra la relazione prevista tra allarme e topic.

Scritto dal modello di indicizzazione a partire dal testo della issue.