Health Monitor scheduled polling and alerting

Implement the transition detection as a Postgres function or Edge Function that uses a CTE to compare current vs new status before upserting: WITH prev AS (SELECT status FROM integration_health_status WHERE org_id=$1 AND integration_type=$2) INSERT ... ON CONFLICT ... DO UPDATE ... RETURNING (new.status != prev.status AND new.status != 'healthy') AS should_alert.

This avoids a separate SELECT round-trip. For the suppression timestamp, add a notification_suppression_until column to integration_health_status — it colocates suppression state with health state and is updated atomically in the same upsert. Dispatch FCM notifications via a separate Edge Function (the existing coordinator notification service) rather than inline in the scheduler, so the scheduler is not blocked by notification failures. The pg_cron schedule string '*/15 * * * *' covers the 15-minute default; store it as a text value in integration_config so it can be changed per-deployment without a code deploy.

Log scheduler_run_log rows regardless of success to maintain a complete audit trail for ops teams.

Unit tests: (1) transition detection logic — healthy→degraded fires notification; healthy→healthy does not; degraded→degraded does not (suppressed); degraded→healthy fires recovery notification and clears suppression; (2) suppression window enforced — second degradation within 60 minutes does not produce second notification; (3) suppression cleared on recovery. Integration tests: (1) pg_cron job exists and is scheduled at correct interval; (2) manual trigger endpoint rejects unauthenticated callers; (3) scheduler_run_log row inserted after each run; (4) FCM dispatch is called with correct device tokens for affected org admins (mock FCM in test environment). End-to-end test: simulate Xledger health check returning 'unreachable', verify FCM notification dispatched and suppression_until set.