feat: support declaration of persistent branches

[nathanparekh]

What kind of change does this PR introduce?

Feature

What is the current behavior?

The supabase_branch resource can only manage preview branches. The API already supports persistent branches via the persistent flag on CreateBranchBody / UpdateBranchBody, but the provider doesn't expose it.

Persistent branches also can't be deleted directly since the delete API returns 422 until they're demoted, so they can't be appropriately destroyed.

What is the new behavior?

Adds an optional persistent boolean to supabase_branch (default false --> preview branch):

• persistent is Optional + Computed, defaulting to false
• Create / Update — send Persistent on CreateBranchBody / UpdateBranchBody, already supported by the API
• Read — refreshes persistent from the API. Because the existing Read path uses V1GetABranchConfig (BranchDetailResponse), which does not carry the persistent flag, a new readBranchPersistent helper calls V1GetABranch(parent_ref, git_branch) --> BranchResponse, which does
• Delete — on 422, tries to demote the branch (PATCH persistent=false) and retry the delete

Additional context

The Read solution is pretty hacky and involves an extra lookup operation every time; it might be worth just letting persistent go stale/treating it as write-only, since it's never necessary to know the correct value. But I've implemented the extra lookup to keep it in sync when read for the time being.

[JEETDESAI25]

Hey @nathanparekh, thanks for adding persistent branch support and for explaining the read-path tradeoff.

I verified the delete behavior against a live project, deleting a persistent branch returns 422 with {"message":"Cannot delete persistent branch."}, and demote-then-delete succeeds, so the destroy approach is sound.

I've left two inline comments: one about documenting the import behavior and one about the lookup key in the read path.

cc @savme

[nathanparekh]

Hi @JEETDESAI25,
Thanks for the review. I've fixed that and added a note about the import limitation in the example.

I agree that the limitation could be better addressed... I'd be happy to work the composite ID into this PR if you think it's important, or as a separate follow up in the future.

[JEETDESAI25]

@nathanparekh Thanks for addressing the feedback and for your contribution.

Listing the parent’s branches and matching by id resolves the lookup concern, and the import limitation is now clearly documented.

Let’s keep composite import IDs as a separate future improvement rather than expanding this PR. No further changes needed from my side.