Implement RLS policies for report history table

Supabase uses PostgreSQL JWT claims accessible via `auth.jwt()`. Ensure the `organization_id` and `role` custom claims are injected at sign-in time (typically via a `handle_new_user` trigger or a Supabase Auth hook). RLS policy expressions like `(auth.jwt() ->> 'organization_id')::uuid = organization_id` are safe and efficient because they use the indexed organization_id column. Avoid joining user_roles inside the policy expression — this creates an N+1 problem.

Instead, use JWT claims as the single source of truth for org and role at query time. For the UPDATE policy, add a USING clause (controls which rows can be updated) and a WITH CHECK clause (validates the new row state) to prevent privilege escalation via UPDATE. Example: `CREATE POLICY ... ON bufdir_report_history FOR UPDATE USING (org_check) WITH CHECK (org_check AND role_check)`.

Test policies with `SET LOCAL role = authenticated; SET LOCAL request.jwt.claims = '...';` in psql.

Write three sets of integration tests: (1) Cross-tenant isolation — create two organizations (A and B), insert one report per org, authenticate as user from org A, assert only org A's report is returned in SELECT; (2) Role enforcement — authenticate as peer_mentor role in org A, attempt INSERT — assert permission denied; authenticate as coordinator in org A, attempt INSERT — assert success; (3) Admin delete — authenticate as admin in org A, DELETE org A's report — assert success; attempt DELETE on org B's report — assert permission denied. Run tests using Supabase local dev (supabase start) with test-specific JWT tokens generated via `supabase functions serve` or the service_role key in a test harness. All tests must pass before policies are applied to staging.