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

N/A — CI-only workflow change, no application code or tests affected.

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-package job into two jobs to decouple release creation from PR management:

1. release-please job — Runs release-please in two passes:

   • Pass 1 (skip-github-pull-request: true): Creates a GitHub release if one is pending. If created, checks out the repo and pushes the tag (with an idempotent guard).
   • Pass 2 (skip-github-release: true): Only runs if no release was created; handles release PR creation/updates.

2. release-package job — Now depends on release-please and is gated on releases_created == 'true'. Individual step-level if guards are removed since the job itself only runs on release.

This two-pass approach ensures the tag exists before release-please evaluates whether a new release PR is needed, preventing duplicate PRs.

Describe alternatives you've considered

A single-pass approach where release-please handles both releases and PRs simultaneously — this is the current behavior and causes issues with GitHub's immutable releases because the tag may not exist when release-please checks PR state.

Additional context

Things for reviewers to verify:

• The release-please job outputs releases_created (plural) for the downstream job gate, but the inline tag-creation conditions use release_created (singular). Both are valid release-please outputs; for this single-package repo they should be equivalent, but confirm this is intentional.
• The release-package job no longer has pull-requests: write permission (previously needed because release-please ran in that job). Confirm no downstream composite action requires it.
• The action pin SHA 16a9c90856f42705d54a6fda1823352bdc62cf38 is unchanged; the version comment was updated from # v4 to # v4.4.0.

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

---

Note

Medium Risk
Changes the release automation workflow by adding manual tag creation and new job gating, which could impact whether releases/tags/PRs are created correctly. No application code changes, but misconfiguration could break publishing.

Overview
Splits the GitHub Actions release flow into two jobs so release creation/tagging is separated from release PR management.

A new release-please job runs release-please in two passes: first to create a GitHub release (skipping PRs), then—only if no release was created—to manage release PRs (skipping releases). When a release is created, the workflow now checks out the repo and creates/pushes the release tag idempotently.

release-package now depends on release-please and only runs when release_created is true, removing the prior step-level if guards and dropping pull-requests: write permissions from the packaging job.

^{Reviewed by Cursor Bugbot for commit f144b07. 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 #19.