Refactor RNW release pipelines to prepare via PRs instead of main-branch commits

Background

Today our release flow is split between two ADO pipelines:

• publish.yml runs on a schedule, uses Beachball to bump versions, generates .tgz packages, publishes them directly to npmjs.com, and creates NuGet packages.
• After that completes, release.yml pushes the NuGet packages to nuget.org.

Because publish.yml commits the version bumps straight to main, we have to keep rotating a PAT with force-push rights. This bypasses branch protection and is increasingly out of line with SDL expectations.

Proposal

Move the version bump and release prep into a scheduled pipeline that raises a release PR, and only build/publish artifacts once the PR merges:

1. Add prepare-release.yml (same cadence as today’s publish.yml):

   • Run beachball bump to update package versions/changelogs and commit them to a release_request/<date> branch.
   • Generate the release manifest and open/update a PR targeting main or the corresponding release branch.

2. When the PR merges, run the existing publish.yml:

   • Build the repo and create npm .tgz plus NuGet artifacts, but do not push to registries yet.

3. Finally, let release.yml publish those artifacts to npmjs.com and nuget.org.

This keeps all commits to main and other release branches going through protected PRs, removes our dependency on elevated PATs, and aligns the release flow with SDL guidance.

This proposal is based on the separate discussions with @jonthysell and @dannyvv that we had last week.

• @jonthysell outlined the whole new process. He proposed to create artifacts before the PR with package version bumps is created.
• @dannyvv expressed concerns about having the version bump PR to match the previously created artifacts. Also, we must have a way to manually fix/override any steps if need to get the repo and releases in a good state.
• This proposal augments the original process suggested by @jonthysell to generate released artifacts after the PR with version bumps (release PR) is merged. Hopefully it should address @dannyvv concerns.
• @dannyvv also proposed to create a process for the end-to-end testing between RNW released and its key consumers. We should consider to implement it in future.
• A quick experiment had shown that our current ADO pipeline can create branches and PRs using the standard permissions.