feat: standing release pull request as the tag merge-gate

[joshua-temple]

Today the release flow is driven by promotion to the top environment, and reviewers see a
breaking-change gate and a per-PR plan-preview comment. Teams that prefer an explicit,
reviewable "this is what the next release will be" artifact have no first-class option.

Add an opt-in standing release pull request. While commits accumulate on trunk, cascade
maintains a single open pull request that shows the next computed semantic version and the
aggregated changelog for the unreleased range. The PR is updated as new commits land.
Merging the PR is the gate that creates the tag and triggers the release.

This is opt-in and additive. When the manifest does not enable it, the current
dispatch-and-promotion release flow is unchanged and remains the default.

Proposed approach:

• New optional manifest block (for example release.pull_request) with at minimum an
  enabled flag and a target branch.
• New generated workflow that opens or updates the release pull request on each qualifying
  trunk push and reacts to its merge.
• Reuse the existing next-version and changelog generation rather than duplicating logic.

Acceptance criteria:

• A manifest with the block disabled or absent generates no new workflow and changes no
  existing output (byte-for-byte stable).
• With the block enabled, a generated workflow maintains one release pull request whose
  body shows the next version and the unreleased changelog.
• Merging the release pull request cuts the tag and runs the release.
• An e2e scenario exercises open, update, and merge of the release pull request.