Support running the workflow on push to main, with prerelease-only-during-open-PR model

[MariusStorhaug]

Context

Reported bug: the Plan/version logic resolves a prerelease on merge to the default branch (e.g. GoogleFonts run 29202094727). The desired model is: a prerelease exists only while a PR is open; when a change lands on the default branch it must be a stable release or nothing — never a prerelease. The clean way to make that structural (rather than a conditional) is to drive stable releases from a push to main trigger instead of the pull_request: closed (merged) event.

Currently, the reported bug is neutralized by a temporary stopgap in Resolve-PSModuleVersion#11 ("prerelease only for open PRs"), but this needs to be made structural in the framework.

Decision

Implement a push to main trigger for stable releases in the Plan/Build/Test/Publish orchestration. The framework logic will route pull_request (open) → prerelease/preview; push to default → stable release; pull_request: closed → prerelease cleanup only.

Plan

Phase 1 — add push: branches: [main] trigger

• Update the caller template in Process-PSModule workflows.
• Add the trigger to all consumer repositories.

Phase 2 — resolve PR context from merge commit

• On push: map merge commit → PR (labels/title/body/head ref) via GET /repos/{owner}/{repo}/commits/{sha}/pulls.
• Update Get-PSModuleSettings to detect event type and resolve version context accordingly.

Phase 3 — split release routing in the dispatcher

• Update Resolve-PSModuleVersion to route: pull_request (open) → prerelease; push → stable; pull_request: closed → cleanup.
• Update Publish-PSModule to handle both paths (prerelease target-ref vs stable GitHub Release).
• Retire the pull_request: closed (merged) release path.

Phase 4 (variant) — dev-branch prerelease channel

An optional refinement: instead of every PR opened directly to main triggering a prerelease, keep one or more long-lived dev branches each with a permanently-open PR to main labeled prerelease.

• Feature PRs merge into dev (not directly into main) → a prerelease is published because dev→main has an open prerelease-labeled PR.
• When dev→main is eventually merged → push to main → stable release, bump type from the dev→main PR label.

Aspect	Default (every PR)	Dev-branch variant
Prerelease trigger	Any open PR to main	Merge into a branch with an open prerelease-labeled PR
Stable trigger	push to main	push to main (same)
Bump-type detection	Label on merged PR (resolved from commit SHA)	Label on the still-open dev→main PR (simpler lookup)
Prerelease granularity	Per-PR	Per-merge-into-dev

Acceptance criteria

• A prerelease is only ever produced while a PR is open; a merge/push to the default branch never shows a prerelease.
• Stable releases are cut by push to main, with PR context resolved from the merge commit.
• The pull_request: closed (merged) release path is retired.
• Existing consumers keep working with no extra inputs.

Related

• Publish-PSModule: Split Gallery publishing from GitHub Release creation #330 (split publish) · Move version calculation to a Plan job (Resolve-PSModuleVersion) so Build and Publish never calculate or mutate versions #326 (version in Plan) · Move version generation from Publish to Build step #176 (version→Plan) · Support running the workflow on push to main #84 (originally tracked push-to-main)