Release cut is not a reviewable repository change

## Problem

The current maintainer-pushed **v*** tag is a valid release decision, but the decision is not represented as a reviewable repository change: the next version, changelog, release contents, and publication timing are only visible after the tag is pushed.

This issue is **not** proposing that CI publish every merge, build arbitrary HEAD snapshots, or create rolling tags. Ordinary pull requests should continue to merge without publishing anything.

There are two separate approvals:

- merging a feature/fix PR approves that code for main;
- cutting a release approves a specific batch of changes, version, changelog, and a set of irreversible registry writes.

*(The npm publication-atomicity defects that were originally part of this issue — a failed publish leaving a public partial release, and existence-only resume — are concrete workflow bugs independent of this process question, and now live in #840.)*

## Non-goals

- No automatic publication for every merge to main.
- No HEAD, nightly, or moving snapshot tag.
- No Git tag or changelog per platform package.
- No independently versioned platform packages.
- No attempt to roll back or overwrite an immutable npm version.

## Proposed design

### 1. Keep one logical product and one version

Treat OpenCodeReview as one Go CLI release: one committed product version, one changelog, one **vX.Y.Z** Git tag, one GitHub Release, and seven npm registry artifacts at the same exact version (six platform packages + the root wrapper, as implementation artifacts of npm's platform-selection model rather than separate release units).

### 2. Add an explicit release cut

Use Release Please only for the version/changelog PR layer, configured as one root Go/CLI release:

- Normal merges update or open the release PR; they do not publish.
- A maintainer merges the release PR when the accumulated changes are ready — that merge is the explicit release approval, reviewable as an ordinary diff (version bump + changelog + contents).
- Release Please does not publish the GitHub Release itself; the existing release workflow does, after artifact publication and verification (see #840 for the ordering requirements).

Release Please fits because the repository already uses Conventional Commit titles and has one logical product. It does not replace the native build or npm publisher.

### 3. Reduce duplicated release metadata

Keep one machine-readable target list (Go OS/arch, npm package name, npm os/cpu, artifact name, packaged binary filename) consumed by the build matrix, npm package generator, checksum verifier, fallback downloader, and smoke tests.

### 4. Use short-lived publication identity

Move npm publication to Trusted Publishing/OIDC with provenance, protected by the release environment, instead of a long-lived NPM_TOKEN in the self-hosted runner's home directory.

## Why not Changesets as the publisher?

Changesets is a good version-intent tool, but it does not build native targets or replace the custom publisher this repository needs either way. A root-only Changesets setup would add per-PR fragments without removing that publisher. For a single-product Conventional Commit repository, Release Please is the smaller version/changelog layer.

## Acceptance criteria

- Ordinary merges never publish.
- A maintainer can review the exact version, changelog, and contents before the release happens.
- One release creates exactly one product tag and one GitHub Release.
- All binaries and npm packages carry the same version.
- No long-lived npm token is required by the release job.

## Large-project references

- Trivy: Release Please for the release cut, followed by a custom multi-platform GoReleaser pipeline: https://github.com/aquasecurity/trivy/blob/main/.github/workflows/release-please.yaml
- Turborepo: one version source, generated platform packages, native-first/root-last publication: https://github.com/vercel/turborepo/blob/main/.github/workflows/turborepo-release.yml
- esbuild: platform packages first, root package and public release last: https://github.com/evanw/esbuild/blob/main/Makefile
- Oxlint/Oxc: generated NAPI packages, product-level tags, post-publish cross-platform smoke tests: https://github.com/oxc-project/oxc/blob/main/.github/workflows/release_apps.yml

Start by reading the existing release workflow and native build/npm publisher, then trace where the Go OS/arch and npm target metadata are duplicated. Compare the proposed Release Please layer and OIDC publication approach with the acceptance criteria. Done means reviewable release cuts, one consistent version and tag, verified artifacts, and no long-lived npm token.

Written by the indexing model from the issue text.