ci: add Cloudflare Pages preview deploys on PRs

[hmziqagent]

What

Adds .github/workflows/web-preview.yml: on every PR push touching web/** or shared/**, it builds web/ and publishes an isolated Cloudflare Pages preview deployment, then posts/updates a sticky PR comment with the preview URL.

Production (master) is completely unaffected — it still deploys only via the existing Deploy Website workflow.

How

Mirrors deploy.yml (build) + pr-checks.yml (trigger/path filter) and reuses the existing CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID secrets:

• Build web/ (bun + node 24, CLOUDFLARE_INCLUDE_PROCESS_ENV=true).
• wrangler pages deploy dist/client --project-name=gpui-query --branch=pr-<N> — the non-master branch is what makes it a preview (served at pr-<N>.gpui-query.pages.dev + a unique <hash>.pages.dev).
• actions/github-script finds the previous preview comment (HTML marker) and updates it, else creates it.

Details

• Trigger: every push to a PR (per your choice), web/** / shared/** / workflow file.
• Concurrency: one in-flight preview per PR; superseded runs cancelled.
• Fork PRs: skipped (github.event.pull_request.head.repo.full_name == github.repository) — they can't see the Cloudflare secrets.
• Permissions: contents: read, pull-requests: write.

Verification

• actionlint clean (exit 0, no warnings).
• YAML parses; build steps are a byte-for-byte match of deploy.yml's proven pipeline.

Activation caveat

A pull_request workflow only fires once the file is on the base branch, so this must merge to master before subsequent web PRs start getting preview URLs.

Caveat

• If the first preview deploy returns 403, the CLOUDFLARE_API_TOKEN is scoped to the production branch only — widen it to allow non-production deploys (one-time, dashboard).
• Preview deployments are public by default (configurable via a Pages access policy).

PR is from a fork (hmziqagent/gpui-query) because the authed account has read-only access to freeoxide/gpui-query.