Re-evaluate branch provisioning on synchronize, not only at PR open

[mcfadd]

What happens today

The GitHub integration decides whether a pull request touches the schema once, at around PR-open time. If the opening commit changes nothing under supabase/, the PR is marked ignored — and a migration added in a later commit doesn't trigger provisioning. The bot states the behaviour in each comment it posts: tasks run on every commit, but only new migration files are pushed, and the suggested remedy is to close and reopen the pull request.

What I observed

On a private repo using Git-based branching, two PRs on the same day:

• PR A — opening commit touched no supabase/ file. The bot commented about 80 seconds later that the PR was ignored, no changes detected in the supabase directory. About an hour after that, a later commit added a real migration under supabase/migrations/. The bot's comment had identical created_at and updated_at — never re-posted or edited — and list_branches on the parent project showed no branch for that PR more than an hour after the migration landed.
• PR B, control — migration present in the opening commit. Branch appeared within about 13 minutes, status: FUNCTIONS_DEPLOYED.

Why it's worth changing

Adding a migration part-way through a PR is an ordinary way to work: a reviewer asks for a column, or a scope correction turns out to need one. Any project that gates CI on the branch database — running an end-to-end suite against it, for example — depends on the branch existing, so a PR that takes this shape has to be closed and reopened before it can go green. That works, but it churns the preview through a teardown and rebuild for what is a one-line evaluation decision upstream.

Why it isn't fixable from the client side

POST /v1/projects/{ref}/branches has no pr_number parameter, and pr_number is the only field linking a branch back to its pull request. Falling back to matching on git_branch isn't safe — across a fork or a renamed head it could resolve a PR to another PR's database. So a CI script can't create the branch itself and have it resolve correctly; only the integration can.

The ask

1. Re-evaluate the schema-touching decision on every synchronize event, not only near PR open.
2. Alternatively, expose a Management API call that forces re-evaluation for a PR without a GitHub-side close/reopen. I couldn't find one in the docs — happy to be pointed at it if it exists.

Either one would resolve it. This isn't specific to my setup: any repo combining Git-based branching with a migration-aware CI gate hits it the same way.

Related: #47427, #41543.