ci: grant pull-requests:write to Release (v2) and (v3) workflows

[sherwinski]

One Line Summary

Add pull-requests: write to both the Release (v3) and Release (v2) workflows so the reusable create_release job can open the release PR.

Motivation

The most recent Release (v3) run (for v3.9.0) failed at the release / create_release step with:

pull request create failed: GraphQL: Resource not accessible by integration (createPullRequest)
##[error]Process completed with exit code 1.

The job log shows the token reached the job with only:

GITHUB_TOKEN Permissions
  Contents: write
  Metadata: read

That job invokes OneSignal/sdk-shared/.github/workflows/create-release.yml@main, which calls gh pr create. A reusable workflow can only ever narrow — never expand — the caller's permissions, so the lack of pull-requests: write on the caller (.github/workflows/release.yml) prevents the reusable workflow from creating the release PR.

release-v2.yml has the identical structural issue (same reusable workflow, same missing permission), so a future Release (v2) dispatch would fail with the same error. Patched in lockstep, matching the convention established by #420 and #421.

Companion to #420, which fixed the analogous permissions/token issue for the prep / prepare_release job in both workflows but did not add pull-requests: write.

Scope

• Affected: .github/workflows/release.yml (Release (v3)) and .github/workflows/release-v2.yml (Release (v2)). All jobs in both pipelines now run with pull-requests: write. Only the release job needs it for gh pr create; the others are unaffected by the broader scope.
• Not affected: Runtime plugin code, the reusable workflow in sdk-shared, any other workflow in this repo.

Testing

Manual

1. Merge this PR.
2. Run Actions → Release (v3) → Run workflow against main with version: 3.9.0 (the in-flight release).
3. Confirm the release / create_release job no longer errors at gh pr create and that PR chore: Release 3.9.0 is created/updated against main.
4. (Next v2 release) Same verification against release-v2.yml when the next v2 patch is dispatched.

Note: because rel/3.9.0 and the chore(release): v3.9.0 bump commit already exist from the previous failed run, the re-dispatch will rebase the existing branch and run bump again. The sed-based edits in bump-version are idempotent, but the awk step that inserts a new = 3.9.0 = block into readme.txt is not — expect a duplicate changelog entry that may need to be cleaned up on rel/3.9.0 before the release PR is merged. Will file a follow-up to make bump-version idempotent.

Unit / Integration

• composer test passes locally — N/A, workflow-only change.

Affected code checklist

• PHP plugin code (v3/)
• v2/ legacy code
• JS / CSS assets
• Build / CI
• Tests
• Documentation (README, readme.txt, etc.)

Checklist

• Code follows existing style in the touched files
• Tested manually in the relevant editor(s) — N/A, CI permissions change
  • Gutenberg/Block editor
  • Classic editor
• No new lint or test errors introduced
• Linear ticket / GitHub issue linked above — no ticket
• readme.txt and plugin version bumped if user-facing (release PRs only) — N/A

[claude]

LGTM — one-line permissions fix matching the cited failure mode.

Extended reasoning...

Overview

This PR adds a single line — pull-requests: write — to the top-level permissions block of .github/workflows/release.yml. The motivation is documented with the exact failing log line from the v3.9.0 release dispatch, and matches GitHub Actions' standard requirement for gh pr create in the reusable create-release.yml workflow.

Security risks

Permissions are widened only for the dispatch-triggered Release (v3) workflow, which is already a privileged maintainer-initiated flow. pull-requests: write allows the workflow's GITHUB_TOKEN to create/update PRs in this repo — appropriate for a release pipeline. No secret handling, no third-party code, no runtime/plugin code touched.

Level of scrutiny

Low. This is a mechanical CI permissions change, matches the established lockstep pattern with PRs #420 and #421, and follows the principle-of-least-privilege bump that the cited error explicitly requires. There is no logic to review.

Other factors

The bug hunter flagged a pre-existing parallel gap in release-v2.yml (also missing pull-requests: write); that inline comment is already attached and the author can decide whether to fold it into this PR or a follow-up. It doesn't block approval of the v3 fix, which is correct as written.

[claude]

LGTM — both v2 and v3 callers now grant pull-requests: write, addressing the lockstep concern from my prior comment.

Extended reasoning...

Overview

This PR adds pull-requests: write to the top-level permissions block in both .github/workflows/release.yml (v3) and .github/workflows/release-v2.yml (v2). The change is two identical one-line additions. Both workflows invoke the reusable OneSignal/sdk-shared/.github/workflows/create-release.yml@main, which runs gh pr create and therefore requires pull-requests: write on the caller token (reusable workflows can only narrow, never expand, caller permissions).

Security risks

None of concern. The change only grants a workflow-scoped GITHUB_TOKEN the ability to create/update pull requests, and only on workflow_dispatch runs of the release pipelines — these are manually triggered by maintainers, not by external PR contributors. No new secrets, no new untrusted inputs, no expansion of what code runs.

Level of scrutiny

Low. This is a minimal, mechanical CI permissions tweak that follows the established pattern from companion PRs #420 and #421, which patched v2 and v3 in lockstep. The fix is the documented remedy for the exact Resource not accessible by integration (createPullRequest) error from the v3.9.0 release run.

Other factors

My prior comment on this PR flagged that release-v2.yml had the same structural gap and recommended bundling the fix here to preserve the v2/v3 lockstep. The current diff now includes both files (commit aed68ef adds the v2 line on top of cfcc98c's v3 line), so that concern is resolved. No bugs were reported by the bug hunting system on the latest revision, and there are no outstanding reviewer comments.