Write RLS policy integration tests via Supabase test client

RLS on Supabase can either silently filter rows (SELECT returns [] instead of error) or throw 42501 depending on policy definition. Before writing tests, verify actual policy behavior in psql: `SET LOCAL role = 'authenticated'; SET LOCAL request.jwt.claims = '{"sub":"...","org_id":"..."}'`. Use `SupabaseClient` from `supabase_flutter` with `auth.setSession()` or construct client with a manually signed JWT for test users. Prefer creating test users via `supabase.auth.admin.createUser()` using service role client rather than signing up normally, to avoid email confirmation flow.

Store local Supabase URL and keys in a `.env.test` file loaded via `flutter_dotenv` or `String.fromEnvironment`. Structure test file as `bufdir_report_history_rls_test.dart` under `test/integration/`. Tag with `@Tags(['integration'])` so CI can exclude them from unit test runs. Run with `flutter test --tags integration`.

Integration tests only — no mocking of the database layer. Each test scenario requires a live local Supabase instance. Test structure: (1) setUp creates two organizations, one user per role (coordinator_a, coordinator_b, peer_mentor, org_admin_a) via service role client; (2) each test uses a dedicated Supabase client initialized with the appropriate user JWT; (3) tearDown deletes all seeded rows via service role client. Scenarios: cross-org SELECT isolation, peer mentor INSERT rejection, admin DELETE within org, unauthenticated access rejection, cross-org UPDATE rejection.

Use `expect(() async => ..., throwsA(isA()))` or verify empty result sets depending on RLS behavior (RLS may silently filter rather than throw). Document which behavior is expected per policy.