ci: publish the release docs from the release run

[max-sixty]

release.yaml reached the docs publish indirectly: push-web-branch force-pushed the release commit to web with the bot's PAT, purely so that push would start publish-web.yaml. Both hops sit behind a required reviewer, so the docs took two approvals in two separate runs to go out.

release.yaml now calls publish-web.yaml directly and builds from the release tag, which holds the same tree web was carrying. push-web-branch still moves web, since that's the base doc-only fixes backport onto, but with the default token: it needs no environment, and its push starts no second publish. So the docs path goes from two gated jobs across two runs to one gated job in the release run.

The remaining gate on github-pages can't be removed while the release event is the trigger: tend treats on: release as bot-steerable, so a deployment-branch policy can never gate an environment the release reaches, and actions/deploy-pages requires both id-token: write and the github-pages environment.

One smaller piece rides along: a callee can't request a scope its caller lacks, so both call sites of publish-web.yaml now grant the pages and id-token scopes actions/deploy-pages needs — tests.yaml's pr-publish-web path was missing them too.

One consequence worth naming. The release's web build now runs on a tag rather than on web, and cache scoping lets a web run restore only web's own caches and main's. main's version has bumped by the time a backport lands, so its key no longer matches, which makes the first web build after a release a cold one. Backports are rare enough — the last was October 2024 — that this looked cheaper than the alternatives.

Nothing on the release path can be exercised without cutting a release. If publish-web ever fails in a release run, re-running that job or dispatching publish-web on the tag recovers it.

This was written by Claude Code on behalf of max-sixty

[prql-bot]

One point on the build-web cache change; the rest reads correctly to me.

GitHub scopes caches by ref — a run can only restore caches created on the current ref or the default branch, and the caching reference calls tags out explicitly ("Workflow runs also cannot restore caches created for different tag names"). So a cache saved on refs/tags/0.13.x isn't visible to a later run on refs/heads/web; that run restores main's cache, which save-if already covered. The tag save does still warm a re-run of the release job or the workflow_dispatch-on-the-tag recovery you describe in the description, so keeping it is reasonable — it's the comment that promises something the scoping rules don't deliver.