Validate and test RLS policy scope and bypass resistance

The most common failure mode in RLS testing is accidentally using the service_role key for the 'should-be-blocked' tests — double-check that the anon and coordinator clients are initialized without elevated keys. For seeding coordinator JWT, either use a pre-seeded test user with coordinator role or generate a JWT with the local Supabase auth helper. The filter-injection bypass test is particularly important for security assurance: PostgREST applies RLS before applying client-provided filters, so `WHERE id = ? AND expiry_date < NOW()` will still be blocked if the RLS policy says otherwise — but this must be explicitly verified, not assumed.

Consider writing a test helper `SupabaseRlsTestHelper` with methods `seedExpiredMentor()`, `seedActiveMentor()`, and `cleanupTestMentors()` to keep test bodies readable. Tag all tests in this file with `group('RLS: expiry policy', ...)` for easy filtering in CI.

These tests ARE the deliverable. Use flutter_test with a test helper that initializes a Supabase client against `http://localhost:54321` (local Supabase). Seed data setup: use setUp() to insert test mentor rows into peer_mentors and corresponding rows in certification_expiry_tracking. Use tearDown() to delete seeded rows by test-specific IDs.

For the anon role test, initialize a second Supabase client with the anon key and no session. For the service_role bypass test, use the service_role key (from env vars). For the client-side filter bypass test, attempt `.from('peer_mentors').select().eq('id', expiredId).gt('expiry_date', DateTime(2000))` — the RLS should still suppress the row. Document in the test file header that these tests require `supabase start` to be running locally.