Website previews for fork PRs need a workflow_run deployment on a trusted branch #890

A pull_request run from a fork receives no repository secrets — GitHub withholds them from code the PR author controls, regardless of the permissions: block or the environment configuration. So deploy-website-preview.yml cannot deploy a preview for a fork PR at all, and #888 makes it skip with a notice rather than fail at wrangler deploy.

That leaves fork contributors — the more likely contributor in an open-source relay — with no preview, which is exactly the case a site change most needs one for.

What it needs

The standard shape is a two-workflow split:

1. pull_request (unprivileged) builds the site, uploads the built tree as an artifact, and writes nothing else.
2. workflow_run on a trusted branch reads that artifact and deploys it with the secrets available to main.

The security-critical property is that the deploying job never executes fork code: it unpacks a static build, which is data, rather than checking out and running the PR's package.json, build scripts or wrangler config. Even then, the deployed content is attacker-controlled — which is precisely why previews must stay on their own domain and out of the production one (#889 enforces that host boundary in the router).

Open questions worth settling before building it

• does the artifact path survive PR deletion between the two runs
• how to comment on the PR from a workflow_run context, which has no pull_request payload (the run's associated_pull_requests is the route, and it can be empty)
• whether a preview worker should be created for a fork at all, or the build published as an artifact link only

Found while fixing review findings on #888; not attempted there, because improvising a privileged deploy path inside a bug fix is how a supply-chain hole gets shipped.