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)

Empieza leyendo el PR #208 y las definiciones de FanOutConsumer y ApprovalMetricsPublisherConsumer, centrándote en sus propiedades públicas dlqAlarm. Determina si el topic SNS de notificaciones es compartido o inyectado y, después, inspecciona los patrones existentes de pruebas unitarias y síntesis de CDK. Se considera terminado cuando ambas alarmas tienen acciones SNS, las pruebas verifican el ARN del topic y cdk synth muestra la relación esperada entre la alarma y el topic.

Escrito por el modelo de indexación a partir del texto del issue.