ci: split release-please into independent release and PR creation steps

[keelerm84]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Follows the pattern established in ld-relay PR #622 to support GitHub's immutable releases.

Describe the solution you've provided

Splits the single release-please-action invocation in the release-package job into two independent passes:

1. First pass (skip-github-pull-request: true): Attempts to create a GitHub release only. If a release is created, the workflow checks out the repo and pushes the tag explicitly (with an idempotency guard).
2. Second pass (skip-github-release: true): Only runs if no release was created in pass 1. Handles release PR creation/maintenance.

This separation is required because release-please checks for existing tags when deciding whether a release PR is still needed. Without the split, release-please could open a duplicate PR immediately after publishing a release because the tag wasn't yet present.

Tag names are passed through env variables (not inline ${{ }} expansion) to avoid script injection.

Describe alternatives you've considered

A single release-please-action call (the current approach) works until GitHub's immutable releases feature is enabled, at which point the race between tag creation and PR evaluation causes duplicate PRs.

Additional context

• No changes to downstream jobs (build-ruby-gem, build-jruby-gem, publish) — they continue to gate on release-package.outputs.release-created.
• The pinned SHA (16a9c90856f42705d54a6fda1823352bdc62cf38) is unchanged.
• The release-prs step ID on the second call is intentionally different from release to avoid output collisions.

Link to Devin session: https://app.devin.ai/sessions/7d5bda4d9dbe4ae0b950b30a50485e60
Requested by: @keelerm84

---

Note

Medium Risk
Changes the release workflow control flow by separating release creation, manual tag pushing, and PR maintenance; misconfiguration could affect tagging/release automation on main. Limited scope to CI workflow logic only.

Overview
Updates .github/workflows/release-please.yml to run release-please in two passes: first to create GitHub releases without opening PRs, and (only when a release is created) check out the repo and create/push the corresponding git tag with an idempotency check.

If no release is created, the workflow runs a second release-please invocation configured to only manage release PRs (skipping GitHub release creation), avoiding duplicate PRs when tags are created after the release.

^{Reviewed by Cursor Bugbot for commit 05369cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Closing: The split release-please pattern is only needed for repos with artifact uploads. This attestation-only repo doesn't need it. The attestation changes are in PR #377.