A release pull request, and the merge of it publishes

[SPIKESPIGEL404]

Closes the hole at the end of the maintenance system: everything could merge
itself, and then nothing happened. Publishing meant remembering to draft a
release by hand — the step most likely to be forgotten, and the one where
forgetting is least visible.

The flow

  work merges to main  (auto, or by hand)
          │
          ▼
  release-please keeps ONE pull request open
    "chore(main): release 0.2.0"
    · next version, derived from commit subjects
    · CHANGELOG.md written for you
    · rewrites itself as more lands
    · nothing is published while it sits there
          │
          │  ◀── a person merges it.  THE decision to ship.
          ▼
  tag v0.2.0 + GitHub release created
          │
          ▼
  publish.yml  · checks tag == package.json
               · npm ci / build / typecheck / test  ON THE TAGGED TREE
               · npm publish --provenance

That release PR is deliberately absent from plugin-automerge's automation
branch list. It is the gate. A gate that opens itself is furniture.

Two GITHUB_TOKEN facts this is built around

Both are the same rule — a token-driven event triggers no workflow — and
both would have caused silent failures:

1. release-please creates the release with GITHUB_TOKEN, so
   publish.yml's release: published trigger would never fire. Hence
   workflow_call: the publish is invoked, not waited for. The release
   trigger stays for a hand-drafted release, which is how the first version
   goes out — there's no previous release for release-please to count from yet.

2. A merge performed by GitHub's auto-merge is attributed to
   github-actions[bot], so a Dependabot PR that merges itself never
   reaches release.yml's push trigger. Hence the daily schedule — without
   it the release PR would quietly stop reflecting anything that merged on its
   own.

That second one is not hypothetical. Four Dependabot PRs auto-merged this
afternoon (TypeScript 7, @types/node 26, vitest 4, and on pi the
pi-coding-agent harness bump) and no CI ran on main for any of them. I
verified all three main branches build and test green by hand; they do. But
that verification was manual, and it should not have to be — see below.

Before this does anything

NPM_TOKEN as a repository secret and an npm environment. Until both exist,
the publish job is the only part that fails; release-please will happily keep
its PR current without them.

Still open, separately

With strict: false branch protection, independently-green PRs can combine
into a broken main and nothing checks — and auto-merged pushes don't run CI
on main either. Worth deciding on: a merge queue, strict: true, or a
scheduled CI run on main.