ci: drive releases with release-please and Communique notes

[ThomasK33]

Summary

Replaces the changelog/release machinery (the [Unreleased] bot-PR workflow, the release/* changelog workflow, and the local release:prep / release:finalize scripts) with a single release-please-driven flow that keeps Communique as the changelog author:

• One standing release PR (title chore(release): <version>) maintained on every push to main, carrying the version bump plus a Communique-written CHANGELOG.md section. Merging it is the release: the next workflow run creates the v<version> tag + GitHub Release and dispatches the existing tag-driven release.yml publish pipeline (which is unchanged).
• release-please runs as a library, not the stock action: the action only supports its built-in changelog generators, so src/tools/release-please-runner.ts registers Communique via registerChangelogNotes('communique', ...) (communique generate HEAD <last-tag> --concise, previous tag passed explicitly so both tools agree on the range). Precedent: npm/template-oss runs release-please the same way.
• ## [Unreleased] stays at the top of CHANGELOG.md — Communique hard-requires the heading and feeds its body to the LLM as draft material to reconcile into generated notes. Release-please's stock updater would insert new sections above it, so a custom updater (wired via a node-strategy subclass) inserts release sections below the anchor and clears any reconciled draft so it can't leak into later releases. Maintainers can stage draft wording under [Unreleased] in a small PR and Communique folds it into the next release's notes.
• Version selection from Conventional Commits with bump-minor-pre-major + bump-patch-for-minor-pre-major, matching the project's pre-1.0 history (breaking → minor, feat/fix → patch). Release-As: footers override.
• New CHANGELOG headings drop the v (## [0.4.2] - <date>): release-please recovers the version from the merged PR body with a parser that requires a digit right after the bracket — with a v there, merge would create no release. Unit tests pin this contract against the installed release-please internals. Generated bodies are also normalized against LLM drift (stray H2 section headings demoted to the house ### style).
• Token-event workarounds reuse the repo's existing pattern: workflow-token pushes/tags trigger nothing, so the runner's outputs drive explicit gh workflow run dispatches (CI + validate-skills onto the release branch, release.yml by tag input).
• Supply chain: release-please is an exact-pinned devDependency. Its CJS-only octokit 9.x line ships no npm provenance, so @octokit/endpoint@9.0.6 gets a documented trustPolicyExclude in the new pnpm-workspace.yaml (which also pins an explicit supportedArchitectures matrix so lockfile regeneration stays host-independent — aube add on macOS had silently dropped the linux/win32 optional-dep entries).
• ADR 0009 records the decision; ADR 0002 (release-it for release prep) is superseded. docs/RELEASE-PROCESS.md rewritten for the new flow.

What releasing looks like now

1. Review the standing release PR (version + changelog section).
2. Approve + merge it — the bot authors it, so maintainer review satisfies the ruleset; no admin bypass, no local scripts, no manual tagging.
3. The merge run tags, creates the GitHub Release, and dispatches release.yml (quality gates → verified tarball → editorial Communique notes + assets → npm trusted publish), all as before.

Verification

• 1291 unit tests pass, including round-trip tests that exercise the installed release-please internals: PR-body → version/notes parse-back, the no-v heading constraint, chore(release): ${version} title parsing, and the Unreleased-aware updater (insert below the anchor, clear staged drafts, self-heal a missing heading).
• actionlint + zizmor clean; format/lint/typecheck/build green.
• Live --dry-run with a real ANTHROPIC_API_KEY against this branch: Communique generated real curated notes for these changes, the candidate PR came out as chore(release): 0.4.2 with a parseable body, and the changelogPreview showed exactly the intended file shape — empty [Unreleased] on top, new ## [0.4.2] section below it, historical ## [v0.4.1] untouched.

After merging (operational notes)

• The first push to main after merge opens the first release PR — sanity-check its version + notes before merging it.
• An open automation/update-unreleased-changelog PR (if any) should be closed; its workflow no longer exists.
• Requires the existing ANTHROPIC_API_KEY secret (or OPENAI_API_KEY + COMMUNIQUE_MODEL var) — same contract as the retired workflows.

🤖 Generated with Claude Code