Performance validation: sub-500ms query benchmark

Seed data must mirror NHF's real distribution: 1,400 chapters, each with ~5–15 peer mentors, and each peer mentor with ~50–200 historical activities, to stress the index at production scale. Use PostgreSQL's `generate_series` or a Dart seed script calling Supabase bulk insert. For EXPLAIN ANALYZE, connect via `dart:io` Process to `psql` or use the `postgres` Dart package directly (bypassing Supabase client) to capture raw query plans — the Supabase REST client does not expose EXPLAIN output. Key pitfall: Supabase's connection pooler (PgBouncer in transaction mode) can add ~10–30ms overhead per call; benchmark against the direct PostgreSQL connection string (port 5432) to isolate true query latency from pooler overhead, and document both numbers.

For the composite index, confirm it covers columns in the order used by the WHERE clause to maximize selectivity. If p95 fails, first try a partial index filtering on `is_deleted = false` before more invasive rewrites.

This task IS the testing artifact. The benchmark script itself constitutes the primary deliverable. It must: (1) use a Dart script or SQL migration to seed realistic volume data; (2) invoke check_activity_duplicates via Supabase RPC client in a loop (minimum 100 iterations) to produce statistically stable latency measurements; (3) capture EXPLAIN ANALYZE output from a direct PostgreSQL connection and assert index usage; (4) compute p50/p95 from measured round-trip times; (5) assert p95 < 500ms and exit non-zero if violated, enabling CI gating. A secondary integration test should verify that the benchmark script itself runs idempotently (running it twice produces the same measurements within ±20% tolerance).