Write integration tests for StatsRepository

Use supabase_flutter's SupabaseClient initialised with test credentials injected at runtime via --dart-define or a .env.test file read by flutter_dotenv. Create a TestAuthHelper that mints coordinator and org-admin JWT tokens by calling the test Supabase Auth API with pre-seeded test user credentials. Wrap each test group in a setUpAll / tearDownAll pair: setUpAll runs the seed SQL via the Supabase management API or a direct postgres connection; tearDownAll deletes seeded rows. For performance assertions, wrap the repository call in a Stopwatch, run it 5 times after a warm-up call, and assert that the median is under 100 ms.

For cache behaviour, inject a request-counting HttpClient adapter into the Supabase client so you can assert exactly how many network calls were made. For access-denial tests, catch the thrown exception and verify its type — do not rely on an empty result set as a proxy for denial because that could mask data leaks.

Integration tests using flutter_test against a dedicated Supabase test project (separate from staging and production). Maintain a SQL seed script (test/fixtures/stats_seed.sql) that inserts a deterministic dataset including: 3 coordinators across 2 organisations, 5 peer mentors per coordinator, activities spanning three calendar years with all supported types, and at least two boundary-date activities per period type. Write test groups: period_filtering (monthly, quarterly, annual, boundary dates), activity_type_filtering, scope_isolation (coordinator, org_admin, cross-coordinator denial), cache_behaviour (hit, miss, invalidation), and performance (timing assertions with Stopwatch). Teardown must DELETE only rows inserted by the seed script using a known seed_run_id column.

Run with flutter test integration_test/ --dart-define=SUPABASE_TEST_URL=... --dart-define=SUPABASE_TEST_ANON_KEY=...