Add Idempotency Guards to Cron

Create the migration file first and run supabase db push locally to verify the table and constraint are created correctly before writing the idempotency module. In idempotency.ts, use a single .select('id').eq('certification_id', id).eq('action_type', action).eq('run_date', date).maybeSingle() query for the check — maybeSingle() returns null rather than throwing when no row is found, making the check cleaner. For markAsProcessed, use .insert({ certification_id, action_type, run_date }).select() and check for a 23505 PostgreSQL error code (unique_violation) in the error response to distinguish a race-condition duplicate from a genuine insert failure. Run the idempotency check and mark in the same logical unit as the service call: check → call service → mark.

Do not mark before the service call succeeds, as a failed service call that is marked as processed would never be retried. Consider adding a status field to the log table ('success' | 'failed') to support future retry logic.

Write Deno unit tests in supabase/functions/certification-expiry-cron/idempotency_test.ts. Mock the Supabase client to return an existing row for isAlreadyProcessed and assert it returns true. Mock to return empty rows and assert it returns false. For markAsProcessed, mock a successful insert and assert no error is thrown.

Mock a 409/unique-constraint error response and assert the error is swallowed without re-throwing. Write an integration test using a local Supabase instance: invoke the cron function twice on the same date and assert the certification_expiry_cron_log table contains exactly one row per (certification_id, action_type, run_date) combination after both invocations. Assert that the second invocation's response body contains processed: 0 and skipped: N where N equals the number of certifications in the windows.