Create follow_up_notification_log migration

Use the Supabase CLI (`supabase migration new follow_up_notification_log`) to generate the migration file shell. Write both an `up` and `down` migration. Use `gen_random_uuid()` as the default for log_id to avoid importing pgcrypto separately. The idempotency_key should be constructed by callers as a deterministic hash (e.g.

SHA-256 of `{peer_mentor_id}:{scenario_rule_id}:{date_window}`) — document this convention in a comment inside the migration file. Do NOT define RLS in this migration — RLS is handled in task-004. Ensure the FK on scenario_rule_id has `ON DELETE CASCADE` so that deleting a rule automatically clears its delivery history. Place composite index creation AFTER the table creation statement.

Avoid using SERIAL for primary key — UUID is required for distributed consistency across potential future multi-region setups.

Unit tests are not applicable for raw SQL migrations. Integration tests must: (1) apply the migration to a local Supabase instance and assert all columns exist with correct types using `information_schema.columns`; (2) attempt to insert a duplicate idempotency_key and assert a unique constraint violation is raised; (3) attempt to insert a row with null idempotency_key and assert a NOT NULL violation; (4) insert a valid row and verify all CHECK constraints accept valid enum values; (5) insert an invalid delivery_channel value (e.g. 'sms') and assert rejection; (6) run the rollback migration and verify the table no longer exists. All tests should run against a fresh local Supabase instance using `supabase start`.