Implement RLS policies for badge tables

Use Supabase's `auth.jwt()` function to extract custom claims: `(auth.jwt() ->> 'organisation_id')::uuid` for organisation scoping and `auth.jwt() ->> 'role'` for role checks. Define policies in a separate migration file from the schema (e.g., `supabase migration new badge_rls_policies`) to keep schema and security concerns separated. For the superadmin bypass pattern, use `auth.jwt() ->> 'is_superadmin' = 'true'` as an OR clause in every policy. Document the expected JWT payload shape at the top of the migration file.

Be careful with `USING` vs `WITH CHECK`: `USING` controls which rows are visible for SELECT/UPDATE/DELETE, `WITH CHECK` controls which rows can be written. Both are needed for INSERT and UPDATE policies. Test with `set_config('request.jwt.claims', ...)` in pgTAP to simulate different user contexts.

Write Supabase RLS tests using the `supabase/tests` pgTAP framework or a dedicated test Dart file that exercises the Supabase client with different user JWT tokens. Required test scenarios: (1) volunteer from Org A can read own earned badges, (2) volunteer from Org A cannot read earned badges of another user in Org A, (3) volunteer from Org A gets empty result when querying Org B data, (4) coordinator can read all earned badges in their org, (5) coordinator INSERT succeeds for own org, fails for other org, (6) superadmin reads across all orgs successfully, (7) attempt to UPDATE organisation_id on earned_badge is blocked. Each scenario must have a passing assertion. Run these as part of CI against a local Supabase instance.