feat(release): add prerelease_backmerge_sync_enabled input (opt-in, default false)

[bedatty]

Context

backmerge_enabled currently gates two unrelated behaviors under a single flag:

1. Post-release backmerge on backmerge_source (e.g. main) right after a stable release — proactive, low blast radius (only fires when a release just happened on that branch).
2. Pre-version-calculation sync on prerelease branches (develop, release-candidate) — reactive: merges backmerge_source in before calculating the next version, and skips/blocks the release for that run (opening a PR instead) if the merge can't complete directly. This can fire on any push to those branches, regardless of what the triggering commit touches — surfaced this in plugin-br-pix-indirect-btg (bumping to v1.42.0 blocked an unrelated CI-only PR's release because main/develop had drifted for months).

Callers who want (1) without (2) had no way to disable just the reactive part — backmerge_enabled: false disables both.

Changes

• Adds prerelease_backmerge_sync_enabled (boolean, default false, opt-in) to release.yml, gating the pre_sync step independently: if: inputs.backmerge_enabled && inputs.prerelease_backmerge_sync_enabled && ....
• Exposes it as a pass-through input in go-release.yml.
• Documents it (and the pre-existing, previously undocumented prerelease_branches input) in docs/release-workflow.md.

Behavior

• Default (false): the pre-version-calculation sync never runs. Callers keep computing the next prerelease version from local branch history only — no skip/block, no automatic PR against develop/release-candidate. The post-release backmerge on backmerge_source (e.g. right after a main hotfix) is unaffected either way.
• Opt-in (true): restores the pre-sync check for callers who want the stricter guarantee (next prerelease version always calculated against a develop/release-candidate that's up to date with backmerge_source).

Note on defaulting to false

This input is new, so there's no existing caller relying on the pre-sync behavior via this specific flag — defaulting to false here doesn't silently change anyone's pinned behavior. It does mean callers who upgrade to a version of go-release.yml/release.yml where the underlying pre_sync step first shipped (v1.41.0+) and want that stricter guarantee need to explicitly opt in with prerelease_backmerge_sync_enabled: true.

Verification

• python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))" / same for go-release.yml — both parse cleanly.
• Traced all downstream references to steps.pre_sync.outputs.action (the "warn about pending sync", "determine next version (dry-run)", and "Semantic Release" steps) — all treat a skipped pre_sync step the same as action not being pr-opened/pr-existing (empty string), so disabling the step falls through to normal version calculation, as intended.

[coderabbitai]

Walkthrough

Adds a prerelease_backmerge_sync_enabled boolean input (default false) to go-release.yml and release.yml, forwards it between the two workflows, and gates the prerelease backmerge pre_sync step on that input plus the existing prerelease checks. Documentation adds two input rows.

Changes

Backmerge sync toggle

Layer / File(s)	Summary
Input definition and gating logic in release.yml .github/workflows/release.yml	Adds prerelease_backmerge_sync_enabled as a boolean workflow input with default: false, and updates the pre_sync condition so prerelease backmerge sync runs only when backmerge is enabled, the branch is prerelease, and this new flag is true.
Input forwarding from go-release.yml .github/workflows/go-release.yml	Adds the same reusable-workflow input with default: false and passes it through the release job with block into release.yml.
Documentation of new inputs docs/release-workflow.md	Adds prerelease_branches and prerelease_backmerge_sync_enabled entries to the inputs table, including descriptions and defaults.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• LerianStudio/github-actions-shared-workflows#429: Related backmerge workflow changes in the same release workflow family.
• LerianStudio/github-actions-shared-workflows#530: Also changes prerelease backmerge sync behavior in release.yml.
• LerianStudio/github-actions-shared-workflows#531: Touches the same prerelease/backmerge flow and guards in release.yml.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is concise and matches the main change: adding the prerelease_backmerge_sync_enabled release input.
Description check	✅ Passed	The description covers the workflow change, behavior, default, and verification, though it doesn't follow the template headings exactly.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/prerelease-backmerge-sync-toggle

---

_{Comment @coderabbitai help to get the list of available commands.}

[lerian-studio]

🛡️ CodeQL Analysis Results

Languages analyzed: actions

✅ No security issues found.

---

_{🔍 View full scan logs | 🛡️ Security tab}

[lerian-studio]

🔍 Lint Analysis

Check	Files Scanned	Status
YAML Lint	2 file(s)	✅ success
Action Lint	2 file(s)	✅ success
Pinned Actions	2 file(s)	✅ success
Markdown Link Check	1 file(s)	✅ success
Spelling Check	3 file(s)	✅ success
Shell Check	2 file(s)	✅ success
README Check	2 file(s)	✅ success
Composite Schema	no changes	⏭️ skipped
Deployment Matrix	no changes	⏭️ skipped

---

_{🔍 View full scan logs}

[lerian-studio]

🔍 PR Validation Summary

✅ PR Mergeable — no blocking failures

Check	Status	Blocking
Source Branch	✅ success	yes
PR Title	✅ success	yes
PR Description	✅ success	yes
PR Size	✅ success	no
Auto Labels	✅ success	no
PR Metadata	✅ success	no

---

_{🔍 View workflow run}