chore: release stable by default, publish betas on demand

[derrickmehaffy]

Inverts the release model, and fixes the bug that made me hand-create the
v5.1.0-beta draft.

Betas become manual

release-please was configured with prerelease versioning, so every release
it proposed was a beta, and the repo could not reach a stable version without a
Release-As: override. Betas are occasional and deliberate; stable is the
normal case.

Now: release-please proposes stable versions only. A beta is a dispatch of
publish.yml:

• mode: next
• version: 5.2.0-beta.0
• target_branch: defaults to main

It stamps that version across all three packages and publishes to next via
npm-prerelease. Publishing stays inside publish.yml because npm's trusted
publishing validates the workflow filename — a second publishing workflow
could not authenticate.

version must carry a prerelease suffix; stamp-version.mjs refuses a stable
one, so no dispatch can put a stable version on npm. Those come only from
release-please and what is committed to package.json. A release event never
stamps — it publishes the version release-please already wrote and tagged.

The real cause of the manual draft

separate-pull-requests: false. From manifest.js:83:

this.separatePullRequests = manifestOptions?.separatePullRequests
  ?? (Object.keys(repositoryConfig).length === 1);

It defaults to true for a single package. Forcing it false kept the merge
plugin active, and merge.js:81 hardcodes the branch to
BranchName.ofTargetBranch(targetBranch) — no component — while the
strategy's getBranchComponent() still returned monorepo. buildRelease
compares those two and aborted:

✔ Pull request contains releases, but not for component:
⚠ There are untagged, merged release PRs outstanding - aborting

It made sense with three packages. With one it is actively harmful. Removed.

Dry run confirms the branch now carries the component, so the comparison
matches — and the bare title is fixed as a side effect:

component:                                                        (empty → componentless body)
branch:  release-please--branches--…--components--monorepo        (component present)
title:   chore: release 5.1.0-beta.1                              (${version} interpolates)

Verified

The plan step run directly over every mode:

case	result
release, stable	mode=latest dist_tag=latest
release, prerelease	mode=next dist_tag=next (no stamping)
dispatch next + version	stamp_version=5.2.0-beta.0 ref=main
dispatch next, no version	refused
dispatch next, 5.2.0	refused
dispatch experimental + branch / + sha	correct ref
dispatch latest	mode=latest, no ref
../evil and --upload-pack=x branches	rejected

And the stamper directly: SHA path, explicit prerelease path, and a stable
VERSION refused.

After this merges

The next release PR should read chore: release 5.1.0 and, when merged,
release-please should create the draft by itself — that is the thing to
watch, since it is what failed before.

Release-As: 5.1.0