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

[keelerm84]

Summary

Splits the release-please action into two sequential passes to support GitHub's immutable releases. This matches the pattern established in ld-relay PR #622.

Pass 1 (skip-github-pull-request: true): Attempts to create a GitHub release. If a release is created, the workflow checks out the repo and manually creates/pushes the tag (since release-please needs the tag to exist to know a release was already made).

Pass 2 (skip-github-release: true): Only runs if no release was created in pass 1. Creates or updates release-please PRs.

This two-pass approach is required because release-please determines whether to open a new release PR by checking if the tag already exists. Without the split, there's a race where the tag isn't created before release-please tries to evaluate PR state.

Review & Testing Checklist for Human

• Verify that release_created (singular, used in tag creation conditions) and releases_created (plural, used in job output for downstream ci/publish jobs) are both emitted correctly by release-please for this single-package repo
• Confirm the tag creation logic is idempotent — the gh api check guards against duplicate tag pushes, but verify this matches expected behavior
• After merging, trigger the workflow on a test push to main to confirm release-please PRs are still created correctly (the non-release path via pass 2)

Notes

• The pinned SHA 16a9c90856f42705d54a6fda1823352bdc62cf38 is unchanged; only the version comment was updated from # v4 to # v4.4.0 for accuracy
• Tag creation uses github-actions[bot] identity, consistent with the ld-relay reference implementation

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

---

Note

Medium Risk
Changes the release workflow’s control flow and tag creation behavior; a mis-emitted release_created output or tag push failure could block ci/publish from running on release commits.

Overview
Updates the Release Please GitHub Actions workflow to run release-please in two passes: first to create a GitHub release (with PR creation disabled), then—only if no release was created—to open/update release PRs (with release creation disabled).

When a release is created, the workflow now checks out the repo and manually creates/pushes the release tag (idempotently, skipping if the tag already exists). Downstream ci and publish jobs are gated on the new singular release_created output instead of releases_created.

^{Reviewed by Cursor Bugbot for commit 0bb1a72. 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 #16.