fix: wait for branch project refs via the branches endpoint

[sincraianul]

What kind of change does this PR introduce?

Bug fix — fixes #345.

Since v1.7.0, supabase_settings fails on Create/Update when project_ref is a branch ref (e.g. supabase_branch.x.database.id):

Error: Project Not Ready
Project <branch-ref> did not become active within timeout: unexpected status 404: {"message":"Project not found"}

#272 added a waitForProjectActive gate that polls GET /v1/projects/{ref} and treats any non-200 as fatal (a Refresh error aborts retry.StateChangeConf immediately — the "timeout" wording is misleading; it fails on the first poll). Branch refs are not served by that endpoint, so the gate broke the settings-on-branch pattern that worked through v1.6.2 and that Supabase's own example uses (supabase-action-example preview.tf).

Verified against the live Management API with a branch ref (matching the reporter's findings in #345):

Endpoint	Status
GET /v1/projects/{branch-ref}	404
GET /v1/branches/{branch-ref}	200, status: ACTIVE_HEALTHY
GET /v1/projects/{branch-ref}/health	200, all services
GET /v1/projects/{branch-ref}/postgrest	200

So only waitForProjectActive needs changing — the config and health endpoints all accept branch refs, meaning waitForServicesActive / waitForAuthServiceActive already work.

What is the current behavior?

waitForProjectActive aborts on the projects endpoint's 404, so supabase_settings (and anything else gated on it) can never apply against a branch ref. Reported in #345.

What is the new behavior?

On 404 from GET /v1/projects/{ref}, waitForProjectActive falls back to GET /v1/branches/{branch_id_or_ref} (V1GetABranchConfigWithResponse). BranchDetailResponse.Status shares the project status vocabulary (ACTIVE_HEALTHY, COMING_UP, INIT_FAILED, …), so it feeds the existing state machine unchanged — including fail-fast on terminal states and polling on transient ones. Refs unknown to both endpoints still fail with the original error, so the race #272 fixed (#239) stays fixed for real projects.

Tests:

• Unit tests for the fallback: active branch, transient→active polling, terminal branch state, ref unknown to both endpoints.
• Acceptance test TestAccSettingsResource_BranchRef mocking the full 404→branches-endpoint flow for both create and update of supabase_settings.

Additional context

The status vocabulary trap for anyone touching this later: the branches list endpoint (GET /v1/projects/{ref}/branches) reports a workflow-style status (FUNCTIONS_DEPLOYED, …) plus a separate preview_project_status; only the branch detail endpoint used here reports project-style status directly.

🤖 Generated with Claude Code

[JEETDESAI25]

Hey @sincraianul, Thank you for the fix and the thorough regression coverage.

This looks good to me. Falling back to the branch endpoint only when the project lookup returns 404 fixes settings for preview branch refs while preserving the existing behavior for regular projects. The branch detail status uses the same status vocabulary, so reusing the existing readiness state machine is sound.

No blockers from me @savme.