Implement Supabase trigger for new activities

Structure the trigger function as: (1) DECLARE config record; (2) SELECT config into variable, using COALESCE for defaults; (3) early RETURN NEW if is_active = false; (4) wrap the candidate loop in a BEGIN...EXCEPTION WHEN OTHERS THEN block that inserts into trigger_errors; (5) FOR candidate IN SELECT * FROM get_cross_hierarchy_activity_candidates(NEW.id, config.time_window_hours) LOOP — check candidate.similarity_score >= config.similarity_threshold before inserting. Keep the trigger function focused and short — all heavy logic lives in `get_cross_hierarchy_activity_candidates()` and `calculate_activity_similarity()`. Consider adding a `pg_notify('duplicate_detected', json_build_object('org_id', NEW.organization_id, 'pair_id', inserted_id)::text)` call after each insert so Flutter clients subscribed to Supabase Realtime receive live admin queue updates without polling.

Integration tests (run against a real Supabase test project or local Supabase CLI): (1) insert two activities for the same participant in the same org from different units within the time window → verify a 'pending' row appears in suspected_duplicates within 1 second; (2) insert two activities for different participants → no suspected_duplicates row; (3) insert activity for an org with is_active = false → no suspected_duplicates row; (4) simulate trigger function throwing an exception (e.g. by temporarily dropping a dependency) → verify the activity INSERT still succeeds and an error row is written to trigger_errors; (5) concurrent inserts of two near-duplicate activities → only one suspected_duplicates row (ON CONFLICT DO NOTHING test). Flutter widget test: after submitting an activity via the UI, check the suspected_duplicates stream in the admin BLoC fires.