Add RLS policies for coordinator chapter scoping

Materialised views in PostgreSQL do not directly support RLS — you must either (a) convert them to views that internally join to a base table with RLS, or (b) apply RLS on a wrapper view that SELECTs from the materialised view with a policy filter. Approach (b) is simpler: create view v_peer_mentor_stats AS SELECT * FROM mv_peer_mentor_stats and enable RLS on the wrapper view. Enable RLS on the materialised view itself in newer PostgreSQL versions (15+) if available in Supabase's managed instance — check the Supabase PostgreSQL version before choosing. Use a SECURITY DEFINER function for the coordinator chapter lookup to avoid N+1 policy evaluations: CREATE OR REPLACE FUNCTION get_coordinator_chapter_ids() RETURNS SETOF uuid SECURITY DEFINER AS $$ SELECT chapter_id FROM coordinator_chapter_memberships WHERE coordinator_id = auth.uid() $$ LANGUAGE sql STABLE.

Index coordinator_chapter_memberships(coordinator_id) before enabling RLS to prevent full-table scans on every row evaluation.

SQL regression test script (regression_rls_test.sql): (1) CREATE two test coordinator users with non-overlapping chapter sets using SET LOCAL ROLE / SET LOCAL jwt.claims; (2) SELECT from mv_peer_mentor_stats as each coordinator and assert only their chapters are returned using ASSERT or a pgTAP ok() call; (3) SELECT from mv_chapter_stats as a peer mentor and assert zero rows; (4) SELECT own row from mv_peer_mentor_stats as a peer mentor and assert exactly one row; (5) attempt cross-chapter read as coordinator A for coordinator B's chapter and assert zero rows. Run this script in CI after every migration. Additionally, write a Flutter integration test using Supabase's test client to verify that a real coordinator JWT scopes the PostgREST response correctly.