Health status aggregation and persistence

The trigger-based history copy is the most reliable approach — it guarantees history is always written even if the application code path crashes after the upsert. Implement the trigger as a BEFORE INSERT OR UPDATE trigger that also prunes rows beyond the 96-row cap for the same (org_id, integration_type) pair to bound table growth. For the global admin summary, implement as a Postgres RPC function with SECURITY DEFINER and explicit role check on current_setting('request.jwt.claims') rather than relying on RLS alone, since RLS for SELECT ALL requires a bypass policy. Store the display name for each integration_type in a separate integration_types lookup table (seeded at migration time) so the getOrgHealthStatus join always has a human-readable label even for integrations with no current status row.

Unit tests with mocked Supabase client: (1) getOrgHealthStatus returns correct rows for the given orgId; (2) getHealthTrend respects the hours parameter and returns rows ordered DESC; (3) getGlobalHealthSummary rejects callers without global_admin role. Integration tests against local Supabase: (1) trigger correctly copies updated row to history table; (2) RLS blocks cross-org SELECT; (3) pg_cron cleanup deletes rows older than 30 days without deleting recent rows; (4) unique constraint on (org_id, integration_type) prevents duplicate current-status rows. Test with 97 history rows — confirm only 96 returned for 24-hour trend.