Pull Supabase security and performance advisor lints via the Management API and gate CI on the results

Documented steps

1. Fetch security findings: GET /v1/projects/{ref}/advisors/security (optional query lint_type=sql). The response is {"lints":[...]}.
2. Fetch performance findings: GET /v1/projects/{ref}/advisors/performance, same response shape.
3. Match findings on the documented 'name' field, which comes from a fixed catalogue of rules numbered 0001-0029.
4. Treat these security lints as release blockers: rls_disabled_in_public, policy_exists_rls_disabled, rls_enabled_no_policy, auth_users_exposed, security_definer_view, rls_references_user_metadata, sensitive_columns_exposed, insecure_queue_exposed_in_api, materialized_view_in_api, foreign_table_in_api, public_bucket_allows_listing.
5. Track these performance lints as tech debt: unindexed_foreign_keys, unused_index, duplicate_index, multiple_permissive_policies, auth_rls_initplan, no_primary_key, table_bloat, extension_versions_outdated.
6. Also watch function_search_path_mutable, extension_in_public, auth_allow_anonymous_sign_ins, anon_security_definer_function_executable and authenticated_security_definer_function_executable, which catch privilege-escalation shapes.
7. Fix, then re-run the endpoint and assert the specific lint name is absent rather than assuming the fix worked.
8. Wire the call into CI after each migration so a schema change that disables RLS fails the build.
9. Official documentation: https://supabase.com/docs/guides/database/database-advisors | https://supabase.com/docs/guides/database/database-linter