Give every pull request its own isolated Neon database branch

Build me a code workflow that gives every GitHub pull request its own isolated Neon Postgres branch, so reviewers can test against production-shaped data without ever touching production. Trigger it with a GitHub webhook on pull request events, and route on the event action: "opened" provisions the database branch, "closed" tears it down.

When the action is opened, call Neon's Create branch on my project with the production branch as the parent, so the new branch starts from a copy of real data, and attach a read-write compute endpoint so the branch is immediately connectable. If the compute is not created as part of that same call, follow it with Create compute endpoint for the new branch. Name the branch strictly pr-<number>, using the pull request number from the webhook payload, lowercase and with no other decoration.

Neon's mutating calls are asynchronous. Create branch and Create compute endpoint return an operations array, and the work is not finished when the call returns. Before doing anything that depends on the branch existing, poll Retrieve operation details for each returned operation id until its status is finished. Back off between polls, and fail with a clear message if an operation reports a failed or errored status rather than continuing.

Once every operation reports finished, and only then, use GitHub's Create an Issue Comment on the pull request number to confirm the database branch is ready. The comment should name the branch (pr-<number>) and link to the Neon console so developers can open the branch and pull credentials themselves. Critically, never put the Postgres connection string, the role password, or any other live credential into that comment: it is visible to everyone with access to the repository. Do not call the connection URI or reveal password operations anywhere in this workflow, and never write credentials into logs or saved output.

When the pull request event action is closed, which covers both merged and closed without merging, tear the branch down. Resolve the branch by name using List branches with a search for pr-<number>, take the id of the matching branch, and call Delete branch on it. Deleting the branch also idles and removes its compute, so no separate compute cleanup is needed. If no branch matches that name, treat it as already cleaned up and finish quietly instead of failing the run.

Use Get a Pull Request when the workflow needs to confirm the pull request's current state before acting, for example on a replayed or out-of-order webhook delivery. Keep the naming convention strict in both directions: provisioning always writes pr-<number> and teardown always looks up exactly pr-<number>, so the two halves can never drift apart. If a branch named pr-<number> already exists when a pull request is reopened, reuse it rather than creating a duplicate.