feat(release): cut-rc — snapshot one-click rc release (#7447) (#7453)

* feat(release): cut-rc — snapshot one-click rc release (#7447)

A `workflow_dispatch`-only lane that bumps the objectui pin, versions, gates
and publishes an rc from ONE snapshot, ending the two-repo pin-chasing freeze
dance (rc.6 needed four overtaken pin-bump laps and ~40 min of coordinated
freezes).

The snapshot is the whole idea: objectstack `main` and objectui `main` HEAD are
each resolved exactly once, and every downstream step reads those frozen values,
so both repositories may keep moving for the entire run.

Preserves every invariant of the existing lanes:
- 2026-08-07 manual-publish ruling: dispatch-only trigger, `environment: release`.
- #6170: the version commit lands on `main` FIRST and is published SECOND, so
  nothing is ever published from a ref that only existed inside the run.
- #3340: `check-objectui-pin-fresh.mjs` is unchanged and still enforces on the
  GA path. This lane asserts pin SELF-CONSISTENCY instead of liveness, because
  liveness is exactly what a snapshot gives up; the changeset record still
  covers OLD_PIN..SNAPSHOT by construction.
- #5960: the ADR-0082 D4 declaration-parity ratchet runs here, since this lane
  is now a route that moves the pin.

`release.yml`'s three lanes, `scripts/check-objectui-pin-fresh.mjs` and
`content/docs/releases/**` are untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BPWqbmEFU8gJepBJTHESXd

* docs(release): what happens to the standing Version Packages PR after a cut-rc run (#7447)

A cut leaves #6208 (`chore: version packages (rc)`) in one of two resting
states depending on which push credential the maintainer configured, and the
answer is counter-intuitive enough to be worth writing down rather than
rediscovering mid-incident.

Verified rather than assumed, three ways:
- GitHub documents that events triggered by the automatic GITHUB_TOKEN do not
  create workflow runs, with `workflow_dispatch` / `repository_dispatch` the
  only exceptions. So on route (a) the version-commit push does not fire
  release.yml's push lane and `version-pr` never runs.
- A PAT is not the GITHUB_TOKEN, so route (b) triggers normally and the PR
  self-corrects.
- This repo already depends on the same guard and says so: docker-publish.yml's
  header explains a `push: tags:` trigger "would never fire" because the release
  workflow pushes its tags with GITHUB_TOKEN.

States plainly that a stale #6208 after an rc cut is expected and harmless — its
changesets are consumed and recorded in pre.json, the PR carries no publish
capability by construction — and that the cutter must not fix it by hand.

Also sharpens the runtime-image note while adjacent: the image comes from a
LATER push under both routes, not the cut's own, because on route (b)
`release-integrity` audits long before the cut's publish step reaches npm.

Adds the same two expectations to the workflow's run summary, so the operator
reads them at the moment they would otherwise be surprised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BPWqbmEFU8gJepBJTHESXd

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang