Certificate Expiry Notification Orchestrator

This medium-complexity backend service is central to the certificate expiry feature and must be delivered before the in-app notification banner and detail view can be fully tested end-to-end with real data. It depends on three services — certification-expiry-repository, notification-record-repository, and fcm-push-notification-sender — all of which must be available or properly mocked for integration testing. The duplicate-notification prevention logic (`hasNotificationBeenSent()` and `markThresholdNotified()`) carries high delivery risk: notification spam is a visible failure mode with direct negative user impact and must be covered by dedicated integration tests. Coordinate with the infrastructure team to confirm the scheduled edge function trigger is stable and reliable before end-to-end testing begins, as the orchestrator is invoked by that trigger and cannot be tested in isolation from it.

Core orchestration service invoked by the scheduled edge function, with `processUpcomingExpirations(expirations: List)` as its primary entry point. For each expiry record, `evaluateThreshold(expiryDate: DateTime) -> NotificationThreshold?` determines which of the 60/30/7-day thresholds applies, returning null when no threshold is reached. `hasNotificationBeenSent(mentorId, threshold) -> bool` queries notification-record-repository to guard against duplicate dispatches for the same mentor-threshold pair before any outbound action is taken. `dispatchExpiryNotification()` coordinates a dual write: a push notification via fcm-push-notification-sender and a persistent in-app notification record via notification-record-repository for banner display.

`markThresholdNotified()` writes the sent state atomically after successful dispatch. Depends on certification-expiry-repository for expiry data and peer_mentor_profile for coordinator ID resolution. Threshold evaluation and deduplication logic carry the highest unit test surface area. Backend execution context only.