[Fix] Release promote PR ships unfrozen develop commits and stale runs resurrect Version PRs

[roomote-roomote]

Opened on behalf of Matt Rubens. Follow up by mentioning @openmote, in the web UI, or in Slack.

What changed

The release automation never actually froze a release. The promote PR was opened as head: develop → base: main, so its contents were whatever develop happened to be at merge time — commits merged after the Version PR (like #145 riding into the v0.0.2 promote #146) silently shipped in a release whose changelog never mentioned them, and tag-release.yml then tagged that drifted content on main.

Two fixes:

1. Frozen release cut. The promote job now locates the commit that introduced the current product version (new scripts/release/find-version-commit.mjs, backed by findVersionCommit in scripts/release/lib.mjs with a unit test), pushes a frozen release/v{version} branch pinned at that commit, and opens the promote PR as release/v{version} → main. Later merges to develop wait for the next cut, and the tag lands on exactly the content the changelog describes. The now-unnecessary pending-changesets guard was removed: a new batch of changesets for the next release no longer blocks promoting the already-versioned one.
2. No more zombie Version PRs. release.yml previously queued runs (cancel-in-progress: false) and each run checked out the triggering push SHA, so a stale queued run could execute after a Version PR merged and recreate it from an outdated snapshot (that's how Release Roomote #144 appeared). Superseded runs are now cancelled, and both jobs check out the live develop tip (ref: develop).

CONTRIBUTING.md and .changeset/README.md are updated to describe the frozen release/vX.Y.Z promote flow.

Why this change was made

The first real release cut (v0.0.2) surfaced both problems: #145 rode into the open promote PR after the version bump, and a raced Release run resurrected the merged Version PR as #144. Without a frozen ref, every release can silently diverge from its changelog in both directions.

Impact

• Promote PRs are immutable release cuts: what you review is exactly what gets tagged and shipped to GHCR latest.
• Post-bump merges to develop (and their changesets) cleanly roll into the next release instead of leaking into the current one.
• Stale Release runs can no longer recreate merged Version PRs.
• Promote PR bodies now state the frozen SHA and note that the release/v* branch can be deleted after merge; if multiple promote PRs stack up, they should be merged in version order (oldest first).

Verified with pnpm test:release-scripts (new temp-git-repo test for findVersionCommit), pnpm lint, pnpm check-types, pnpm knip, and a read-only dry run against real repo history: find-version-commit.mjs 0.0.2 origin/develop resolves to eaee303 (the #143 Version PR merge), correctly excluding #145.

[roomote-roomote]

No code issues found. See task

Reviewed the frozen release-cut logic (findVersionCommit + find-version-commit.mjs), the release.yml promote job rewrite, and the concurrency change. The version-commit walk correctly returns the oldest contiguous version-bump commit; verified against real history (0.0.2 → eaee303, excluding #145/#147) and the new unit test passes. The freeze/skip guards (tag check, merge-base --is-ancestor, existing-branch reuse) are self-healing under cancel-in-progress: true, and doc updates match the new flow.