feat: add third-party auth resource

[JEETDESAI25]

What kind of change does this PR introduce?

Feature

What is the current behavior?

The Terraform provider does not support managing Supabase third-party auth integrations. Users need to configure third-party auth outside Terraform.

What is the new behavior?

Adds a new supabase_third_party_auth resource for managing Supabase third-party auth integrations.

The resource supports exactly one auth source:

• oidc_issuer_url
• jwks_url
• custom_jwks

It also includes:

• import support with <project_ref>/<third_party_auth_id>
• public-only JWKS validation for custom_jwks and resolved API responses
• semantic JSON comparison for custom_jwks to avoid replacement on formatting-only changes
• create-time readiness checks for the project and Auth service
• generated docs, schema, and examples
• mocked provider tests for CRUD, import, validation, replacement, drift deletion, and timeout-only updates

Additional context

• Source changes require replacement because the Supabase Management API exposes create/get/delete for third-party auth integrations, not update.
• custom_jwks and resolved_jwks are treated as public verification metadata, not sensitive state. The provider rejects private or symmetric JWK members.
• custom_jwks uses semantic JSON comparison so formatting/key-order-only changes do not force replacement.
• Create waits for the project and Auth service to be ready before calling the third-party auth API.
• Also ran a Terraform CRUD smoke test against a Supabase test project using Clerk as the OIDC issuer. Terraform created the integration, Supabase resolved JWKS and returned type = "clerk-development", a follow-up plan was no-op, and destroy removed the integration.
• The full runtime Clerk JWT/RLS flow was left as optional follow-up validation since this PR focuses on the Terraform resource lifecycle

[savme]

Thank you so much @JEETDESAI25! I wonder if we should follow this up with provider-specific resources that wrap this? For example:

supabase_third_party_auth_aws_cognito {
  project_ref     = "mayuaycdtijbctgqbycg"
  pool_id         = "xyz"
}

This is just an idea for a separate discussion - it is in no way blocking merge!

[savme]

This looks similar to waitForServicesActive. I wonder if we could have a single helper that allows scoping services being checked?

[JEETDESAI25]

Thanks! I agree on both points.

Provider specific convenience resources could be a useful follow up discussion. I kept this PR focused on the generic third-party auth primitive that maps directly to the Management API, but wrappers for Cognito/Clerk/etc sounds good.

For the service readiness helper, good call. waitForAuthServiceActive is intentionally scoped to Auth, but it does duplicate most of waitForServicesActive. I’ll refactor that into a shared helper that accepts the services to check while preserving the existing all services and Data API disabled behavior.