chore: release v20.0.49 - #2018

Required checks are matched against what is attached to the pull
request, and GitHub does not attach check runs from workflow_dispatch
runs. Release PR #2018 shows it: its head commit carries the dispatched
CI's check runs, yet the PR's status rollup lists none of them, only the
`CI (release dispatch)` commit status. Under the new ruleset the release
PR would therefore stay blocked on `ci gate` and on both title checks,
whose dispatched check runs never reach it.

Commit statuses are attached by SHA, so the dispatched runs now report the
exact required contexts that way, using the Actions token so the status
comes from the GitHub Actions app the ruleset names. CI's existing
release status is renamed from `CI (release dispatch)` to `ci gate`, and
the title workflow posts `Validate PR title` and `Validate PR title scope`
from a separate job that runs no repository code. The two title jobs no
longer run on dispatch.

* ci: run CI on merge queue groups

A merge queue only merges a group once the ruleset's required checks
report on the group's commit, and those checks come from workflows that
listen for `merge_group`. CI listened only for push, pull_request and
workflow_dispatch, so a required `ci gate` would never report and every
queued PR would time out.

On merge_group there is no pull_request payload, so change detection fell
back to `github.event.before`, which is empty, and diffed from the root
commit. It now diffs from the merge group's base. The SARIF upload is
skipped there because the same commit is uploaded by its push run on main.
The perf comment already runs only on pull_request. The pkg.pr.new publish
and the e2e matrix keep running: pkg.pr.new records any workflow run and
keys the preview by the checked-out SHA, so the queue tests the package
main will get.

* ci: report PR title checks on merge groups and release dispatches

Both title jobs are about to become required checks, and a required check
must report on every commit the ruleset judges. The merge queue judges the
merge group commit, which has no PR title and is only built from PRs whose
titles already passed. tagpr's release PR is opened with GITHUB_TOKEN, so
its pull_request runs wait for an approval and never report; its CI already
comes from a workflow_dispatch in release.yaml for that reason.

Both jobs now pass without validating on merge_group and on a dispatch from
a tagpr-from-* branch, under the same job names so the check contexts
match. A dispatch from any other branch fails, so a dispatch cannot stand
in for a real title check. release.yaml dispatches the title workflow next
to CI.

* chore(renovate): merge dependency updates through GitHub auto-merge

With a merge queue on main, GitHub rejects direct merges through the API,
which is how Renovate merges when platformAutomerge is off. That setting
came in with the inlined shared preset rather than for this repository.
Platform auto-merge enables GitHub's auto-merge instead, which adds the PR
to the queue once its checks pass.

* docs(skills): merge PRs through the merge queue

`gh pr merge --squash --body-file` merges directly. Under a merge queue the
queue builds the squash commit itself from the repository's settings (PR
title plus commit messages), so a custom body, and the Co-authored-by
trailer it carried for issue reporters, would be lost. The trailer now goes
on a commit in the PR instead.

* ci: upload tirith findings for merge groups

Skipping the SARIF upload on merge_group lost the findings that matter
most there: when tirith blocks a queued commit, that commit never reaches
main, so no push run ever uploads them. Code scanning accepts uploads for
merge queue refs, so the upload runs for merge groups like any other
non-fork run.

The e2e comment no longer ties the queued commit's SHA to the one main
gets; what the queue verifies is the package built from that tree.

* ci: build merge groups without write or Nix credentials

merge_group runs queued code with the permissions the workflow declares,
unlike fork pull_request runs, whose token GitHub caps at read. The native
build job declared `actions: write`, and its Nix build was handed the
GitHub token on every event except pull_request, so a queued fork PR's
build ran with both.

Nothing in the build job uses `actions: write`: artifacts and the Actions
cache authenticate with the runtime token, and cache-nix-action only needs
the API token to purge, which this repository does not do. The job now has
read-only permissions on every event. The Nix token is passed only on push
and workflow_dispatch, which build code already on main or a release
branch.

* ci: stop persisting the token in build and publish checkouts

The native build and the pkg.pr.new publish jobs run code from the
checked-out commit, which on merge_group is queued code that has not
passed its checks yet. Their checkouts kept actions/checkout's default of
writing the job token into .git/config, where that code can read it.
Neither job pushes or fetches with credentials, so the token no longer
stays on disk.

* ci: report required checks for the release PR as commit statuses

Required checks are matched against what is attached to the pull
request, and GitHub does not attach check runs from workflow_dispatch
runs. Release PR #2018 shows it: its head commit carries the dispatched
CI's check runs, yet the PR's status rollup lists none of them, only the
`CI (release dispatch)` commit status. Under the new ruleset the release
PR would therefore stay blocked on `ci gate` and on both title checks,
whose dispatched check runs never reach it.

Commit statuses are attached by SHA, so the dispatched runs now report the
exact required contexts that way, using the Actions token so the status
comes from the GitHub Actions app the ruleset names. CI's existing
release status is renamed from `CI (release dispatch)` to `ci gate`, and
the title workflow posts `Validate PR title` and `Validate PR title scope`
from a separate job that runs no repository code. The two title jobs no
longer run on dispatch.

* docs(skills): keep --squash so merges work with and without a queue

Without a merge strategy, `gh pr merge` fails in a non-interactive session
on a base branch with no merge queue: stacked PRs into feature branches,
and main until the ruleset is enabled. With a queue, gh only warns that the
queue sets the strategy and enqueues the PR, so `--squash` works on both.
`--delete-branch` is still left out, because gh rejects it when a queue is
required.

* ci: retrigger workflows

* ci: decide in ci.yaml that only main persists caches

The Nix sticky disks are keyed by job, not by ref, so pull request and
merge group runs mount the same disk main commits and release builds
read. What keeps their changes out of it is the stickydisk `commit` flag,
and setup-nix-cache derived that flag on its own from the ref. A
merge_group run checks out the queued commit, so that local action is the
queued code's own copy, and nothing in ci.yaml stated the rule.

ci.yaml now sets PERSIST_CACHES from `github.ref == 'refs/heads/main'` and
passes it to every Nix store and Cargo cache save. Non-main runs still
mount main's warm disk, so pull requests keep their cache hits, but they
mount it without committing and the clone is discarded.

This cannot stop a queued commit that edits ci.yaml itself; review before
queuing is that boundary. It stops a change to a local action, or an
unreviewed-code path, from writing a store that main reads.

* ci: re-report release PR statuses when its branch is pushed directly

The release PR's required checks are reported as commit statuses from
runs that release.yaml dispatches after tagpr updates the branch. A person
pushing to the `tagpr-from-*` branch moves the PR head without any
dispatch, so the new head had no `ci gate` or title statuses and the
release PR was blocked again.

tagpr pushes with GITHUB_TOKEN, which starts no workflow, but a person's
push does. CI and the title workflow now also run on pushes to
`tagpr-from-*`, and the same status jobs run for those pushes, so every
head the release PR can have gets the statuses. The trigger is not added to
release.yaml, because its `tagpr` concurrency group would let a
release-branch run replace a pending release run from main.

* ci: post release title statuses only for the tagpr PR head

The branch-prefix check alone let anyone with write access dispatch the
title workflow from a `tagpr-from-*` branch they created and get both title
statuses on any commit. The job now posts them only when the commit is
the head of an open PR from that branch opened by github-actions[bot],
which is how tagpr opens release PRs.