fix: default branch creation

[nathanparekh]

What kind of change does this PR introduce?

Bugfix

What is the current behavior?

The existing createBranch function has a section:

resp, err := client.V1ListAllBranches(ctx, plan.ParentProjectRef.ValueString())
//...
if resp.StatusCode == http.StatusUnprocessableEntity {
 		httpResp, err := client.V1CreateABranchWithResponse(ctx, plan.ParentProjectRef.ValueString(), api.CreateBranchBody{
			BranchName: "Production",
		})
        //...
}

This seems to be intented to create a default "Production" branch if no branches exist for the Supabase project. However, it seems as if the ListAllBranches call returns a StatusOK with an empty list of branches instead of a StatusUnprocessableEntity, which causes this never to fire.

Considering an example .tf file with two resources: the Supabase project resource and a branch resource, then as a result of this bug:

• the branch resource becomes the default branch for the created project
• a later terraform destroy would fail when trying to destroy the created branch resource (since it cannot delete the default branch)

Additionally, once that's fixed, the branch that is created is created as a preview -- not as the default branch -- because it's not set explicitly. So the (incorrect) resulting branches are:

• main (default branch, not in .tf)
• Production (preview, not in .tf)
• branch resource (preview)

What is the new behavior?

createBranch() now creates the "Production" branch (now explicitly set as default) if the response is either 422 or 200 with an empty list of branches. The branch resource then becomes an additional branch that can be deleted, as expected.

Additional context

N/A

[JEETDESAI25]

Hey @nathanparekh, thanks for the fix and for adding a test.

This LGTM! The provider was only bootstrapping the Production branch when the branches API returned 422, but the API can now return 200 with an empty list. Handling both cases fixes the lifecycle issue where the Terraform managed branch could become the default branch and then fail on destroy, I confirmed the regression test covers this behavior.

The explicit is_default: true also ensures the bootstrap Production branch becomes default, and the switch to the WithResponse client variant fits the provider's existing patterns.

A follow-up test for the legacy 422 path would be useful, but I don't think it needs to block this PR. @savme

[savme]

Thank you for the implementation, @nathanparekh, and for the review, @JEETDESAI25! Merging this now 🚀