Implement consent revocation and data deletion

Implement as a Supabase Edge Function (Deno) or PostgreSQL RPC function using BEGIN/COMMIT to wrap the three operations atomically. Use RETURNING count(*) from the DELETE to capture rows_deleted without a separate SELECT. Store the function behind a POST endpoint that accepts { mentorId, orgId } in the body; validate these against JWT claims at the top of the handler before touching the database. For the audit log insert, use a separate INSERT after the DELETE inside the same transaction — if the audit insert fails, the whole transaction rolls back, which is the correct GDPR behavior (deletion without audit is worse than no deletion).

Define a typed Dart class RevokeConsentResult and a sealed exception hierarchy (ConsentAlreadyRevokedException, ConsentUnauthorizedException) for clean error handling on the Flutter side. Avoid using Supabase's soft-delete patterns here — GDPR Article 17 requires hard deletion of personal data.

Unit tests: mock Supabase client to verify transaction structure (revoke + delete + audit in one tx), verify rollback on simulated delete failure, verify 403 on mismatched JWT claims, verify ConsentAlreadyRevokedException on already-revoked consent. Integration tests against a local Supabase instance: seed mentor_locations with 5 rows, call revokeConsent, assert zero rows remain and audit log contains correct metadata. Test all three organization roles (mentor, coordinator, admin) to confirm only the owning mentor can invoke revocation. Test concurrent invocations to verify no race condition leaves partial data.

Coverage target: 90%+ for revokeConsent and its transaction helper.