Write Admin Repository integration tests

Create a `test/integration/admin_repository/` directory separate from unit tests. Use a `seed.sql` file checked into the repo under `supabase/seed/admin_integration_test_seed.sql`. The seed must be deterministic (fixed UUIDs via gen_random_uuid() seeded, or explicit UUIDs). AdminRepository should accept a SupabaseClient parameter for dependency injection — the test passes the locally-connected client directly.

Do not use AdminRlsGuard in integration tests; test the repository in isolation with a pre-authenticated client that already has org_id claims set via SQL (`select set_config('request.jwt.claims', ...)` in the seed). This avoids coupling two components under test simultaneously. Write a `README` in the test directory explaining how to spin up the local stack.

Integration tests using flutter_test against a real local Supabase instance. Tests are NOT unit tests — no mocking of the database layer. Seed the database with: 3 organisations (org_a, org_b, org_c), 10 users in org_a, 5 in org_b, 3 in org_c, each with varying certification states and activity counts. Test groups: (1) org_admin scope isolation — all list/aggregate methods return only org_a data when authed as org_a admin; (2) KPI accuracy — assert exact integer counts against known seed values; (3) model deserialisation — assert every field in every returned typed model is non-null where required; (4) pagination correctness — cursor-based page boundaries are stable; (5) role escalation — super_admin can read all orgs.

Use setUpAll to sign in once per group, tearDownAll to sign out.