feat(get_prs_between_tags): add opt-in fail_on_error

[dcalhoun]

What does it do?

Adds an opt-in fail_on_error: parameter to get_prs_between_tags, defaulting to false so existing callers are unaffected.

The action rescues every StandardError from generate_release_notes and returns the message as the changelog:

rescue StandardError => e
  error_msg = "❌ Error computing the list of PRs since #{previous_tag || 'last release'}: `#{e.message}`"
  UI.important(error_msg)
  error_msg # Use error message as GitHub Release body to help us be aware of what went wrong.

That is the right default when the caller creates the GitHub Release first and would rather ship degraded notes than fail the lane — the error stays visible in the release body.

It is the wrong default when the caller pushes the tag and then creates the release from the computed notes. There, a transient API failure publishes a release whose body reads ❌ Error computing the list of PRs since v0.19.0: ..., which reads as a successful release and is typically only caught by someone reading the release page later. Those callers want the lane to stop while a re-run is still cheap.

Prompted by GutenbergKit#588, where @AliSoftware suggested adding this upstream so the app can use the action directly instead of reaching past it into GithubHelper#generate_release_notes.

This follows the same opt-in shape as #771, which adds fail_on_error to the translation-download actions. No file overlap between the two.

Usage

get_prs_between_tags(
  repository: 'wordpress-mobile/GutenbergKit',
  tag_name: 'v0.20.0',
  previous_tag: 'v0.19.0',
  fail_on_error: true
)

Testing

• Both new specs fail without the production change (verified by stashing it) and pass with it.
• The four pre-existing error-handling specs are unchanged and still pass, confirming the default behavior is preserved.
• Full suite: 1006/1007. The one failure is git_helper_spec.rb:59 (git-lfs detection), which reproduces on a clean trunk in my environment and is unrelated to this change.

Checklist before requesting a review

• Run bundle exec rubocop to test for code style violations and recommendations.
• Add Unit Tests (aka specs/*_spec.rb) if applicable.
• Run bundle exec rspec to run the whole test suite and ensure all your tests pass.
• Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section.
• If applicable, add an entry in the MIGRATION.md file to describe how the changes will affect the migration from the previous major version and what the clients will need to change and consider. Not applicable — the new parameter is optional and defaults to the current behavior.

[AliSoftware]

Looking good 👍

---

cc @iangmaia FYI as you're currently also working on a PR in release-toolkit to add a fail_on_error on a different action (translations-related actions), might make sense to make sure the semantic and description of those params are consistent between the two PRs, even if they are on completely different actions, just for consistency with our wording being aligned on the description of such ConfigItem across actions and such

[dcalhoun]

@AliSoftware thank you for the review and suggestion. 🙇🏻‍♂️

[iangmaia]

might make sense to make sure the semantic and description of those params are consistent between the two PRs

Gave it a go at ef119031