Apply Supabase RLS policies for scenario_rules

The chapter_id JWT claim must be injected during Supabase Auth sign-in using a custom claims hook (database webhook or Edge Function triggered on `auth.users` insert/update). Confirm this claim population mechanism is already in place from earlier auth tasks before implementing these policies. Write policies in a dedicated migration file named e.g. `add_rls_scenario_rules`.

Use `USING` clause for SELECT policies and explicitly do NOT create INSERT/UPDATE/DELETE policies for `authenticated` role — the absence of a permissive policy is itself the denial mechanism. For the service_role bypass, no explicit policy is needed as `service_role` bypasses RLS by default in Supabase — document this in the migration comments to prevent future developers from adding a redundant policy. Test cross-chapter isolation carefully: a misconfigured policy might return an empty set instead of an error, which is correct behavior (RLS silently filters) — make assertions on row count, not on error type.

Integration tests must cover: (1) authenticate as coordinator in chapter A, query scenario_rules — assert only chapter A rows returned; (2) authenticate as peer mentor in chapter A, query scenario_rules — assert only chapter A rows returned; (3) authenticate as coordinator in chapter A, attempt INSERT into scenario_rules — assert permission denied error; (4) authenticate as coordinator in chapter A, attempt to read a row with chapter_id = B by explicit filter — assert 0 rows returned (not a permission error, which would leak schema info); (5) use service_role token to INSERT a rule — assert success; (6) use service_role token to read rules from any chapter — assert unrestricted access. Tests should run against a local Supabase instance with seeded multi-chapter data.