Apply RLS policies for follow_up_notification_log

Two separate SELECT policies are required — one for `peer_mentor` role and one for `coordinator` role. Role detection can be done via a custom JWT claim (e.g. `auth.jwt() ->> 'app_role'`) or via a JOIN to a user_profiles table. The JWT claim approach is strongly preferred for performance (no extra query).

If role-based claims are not yet in the JWT, coordinate with the auth implementation to add them. Since INSERT is service_role only, the PromptHistoryRepository Dart class (task-007) must use the Supabase Admin client (service_role key) or call a Supabase Edge Function that uses service_role internally — the mobile client must NOT hold the service_role key. Consider using a Postgres function with SECURITY DEFINER as an alternative insert pathway. Document this security boundary explicitly in migration comments.

Integration tests must cover: (1) as peer mentor A in chapter X, query log — assert only own entries returned; (2) as peer mentor A in chapter X, query log with explicit filter peer_mentor_id = mentor_B_id — assert 0 rows returned; (3) as coordinator in chapter X, query log — assert all chapter X entries returned regardless of peer_mentor_id; (4) as coordinator in chapter X, query log filtering by chapter Y — assert 0 rows; (5) as peer mentor, attempt INSERT into follow_up_notification_log — assert permission denied; (6) as coordinator, attempt INSERT — assert permission denied; (7) as service_role, INSERT a record — assert success and row is visible via coordinator SELECT. Use seeded data with at least 2 chapters, 2 peer mentors per chapter, and pre-inserted log entries.