ci(coderabbit): make Release-As releases explicit in the release check

The release check claimed a Release-As footer could override the bump
rule, but CodeRabbit's pre-merge checker cannot see commit footers, so a
forced-version release would fail with no stated way through. It now
names both versions and says a maintainer must ignore the check for
such a release.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

.coderabbit.yaml

@@ -5,8 +5,13 @@ tone_instructions: "Be direct and prioritize actionable correctness, safety, CLI
 
 reviews:
   profile: "chill"
-  # Allow explicit @coderabbitai approve / resolve commands to submit review verdicts.
-  request_changes_workflow: true
+  # CodeRabbit requests changes for blocking findings and approves the PR once
+  # they are resolved, the latest commit is reviewed, and every pre-merge check
+  # below passes. This is the current key for the deprecated
+  # request_changes_workflow; setting both keys turns approvals off. Explicit
+  # @coderabbitai approve / resolve commands keep working.
+  auto_approvals:
+    enabled: true
   high_level_summary: true
   poem: false
   # Avoid noisy "review skipped" status comments when CodeRabbit decides not to run.
@@ -32,6 +37,26 @@ reviews:
     - path: "**/*.go"
       instructions: |
         Do not request Plan 9 or other unsupported GOOS/GOARCH shims. The five native prebuilt release targets are linux-x64, linux-arm64, macos-arm64, macos-x64, and windows-x64. Android/Termux is also a supported runtime through the documented android-arm64 source build and Linux artifact fallback. Other GOOS/GOARCH combinations are not a review criterion.
+  pre_merge_checks:
+    custom_checks:
+      - name: "npm release PR validated"
+        mode: "error"
+        instructions: |
+          Merging a release PR publishes the package to npm, so CodeRabbit approves one only after this check passes.
+
+          Decide every item from the PR title and the diff alone. This check does not receive the head branch name, the PR body, or GitHub Check results, so no item depends on them. If an item still cannot be decided from the title and the diff, fail it and say what was missing; never report this check as inconclusive.
+
+          Scope: a PR is a release PR when its title starts with `chore(main): release`, or when its diff changes `version` in `package.json` or any value in `.release-please-manifest.json`. Either signal is enough, so editing the title does not take a release PR out of scope. Every other PR passes this check; say "Not a release PR."
+
+          For a release PR, NEW is `version` in `package.json` after the change, and PREVIOUS is the `"."` value of `.release-please-manifest.json` before the change. The check passes only when all of the following hold. When it fails, list each failed item with the file and the value found.
+
+          1. Title: the title is exactly `chore(main): release NEW`. A malformed or edited title fails this item; quote it.
+          2. Changed files: the diff touches only `package.json`, `package-lock.json`, `.release-please-manifest.json`, and `CHANGELOG.md`. Any other path fails, whether source, tests, workflows, scripts, dependency manifests, or lockfiles.
+          3. One version everywhere: NEW equals the top-level `version` and `packages[""].version` in `package-lock.json`, and the `"."` value in `.release-please-manifest.json`.
+          4. Version-only edits: in `package.json` only the `version` line changes, in `package-lock.json` only the two root version fields change, and in `.release-please-manifest.json` only the `"."` value changes. No dependency, `engines`, `files`, `bin`, `exports`, or `scripts` change is allowed.
+          5. Valid increment: NEW is a plain MAJOR.MINOR.PATCH with no prerelease or build suffix, and it is greater than PREVIOUS.
+          6. Bump level: this repo uses release-please defaults, without `bump-minor-pre-major`. A breaking change bumps MAJOR, even from 0.x to 1.0.0. A feat bumps MINOR and resets PATCH, and a fix bumps PATCH. Read the change types from the new CHANGELOG section: a "BREAKING CHANGES" heading means a breaking change, "Features" means a feat, and every other section, such as "Bug Fixes", "Performance Improvements", "Reverts", or "Dependencies", counts as a fix. NEW must be exactly the next version for the highest change type present. This check cannot see commit footers, so it cannot confirm a `Release-As:` override. When NEW differs from the version these rules give, fail this item and name both versions; a release forced with `Release-As:` passes only when a maintainer ignores this check.
+          7. Changelog: `CHANGELOG.md` gains exactly one new section, at the top, headed `## [NEW](https://github.com/Twigpine/zero/compare/vPREVIOUS...vNEW) (YYYY-MM-DD)`, with at least one entry. Everything below it is unchanged, so no earlier section is edited or removed.
   tools:
     github-checks:
       timeout_ms: 300000
@@ -46,10 +71,11 @@ reviews:
       - "[skip review]"
     labels:
       - "!do-not-review"
+    # github-actions[bot] is not ignored on purpose: it opens the release-please
+    # PRs, and the "npm release PR validated" check has to run on them.
     ignore_usernames:
       - "dependabot[bot]"
       - "renovate[bot]"
-      - "github-actions[bot]"
     # CodeRabbit reviews default-branch PRs by default. This extends automatic
     # reviews to PRs targeting any branch, including release and stacked branches.
     base_branches: