RLS policies for organisation-scoped periodic_summaries

Use `(auth.jwt() -> 'app_metadata' ->> 'active_organisation_id')::uuid` to extract the organisation UUID from the JWT — this avoids joining the profiles/users table per row. Ensure the JWT claim is populated via a Supabase Auth `custom_access_token` hook when the user selects their active organisation at login time. Create policies in a new migration file (not the same file as task-001 schema) for clean separation of concerns. Use `USING` clause for SELECT policies and omit `WITH CHECK` since writes are blocked.

Add a comment in the migration explaining why direct writes are disallowed (writes go through service-role Edge Functions to ensure audit trails and business logic enforcement).

Integration tests using Supabase's RLS test utilities or pgTAP `set_config` approach: (1) simulate a `peer_mentor` JWT for org A and assert SELECT returns only org A rows, (2) simulate a `coordinator` JWT for org A and assert same org-scoped result, (3) simulate a `peer_mentor` JWT for org A and assert zero rows returned for org B's summaries, (4) assert that an INSERT attempted with an authenticated role JWT throws a permission denied error, (5) assert unauthenticated SELECT returns zero rows. Document test organisation UUIDs as fixture constants. Tests must run in CI against a fresh `supabase db reset` environment.