fix: push release PR updates via Git Data API instead of code-suggester

[Kerwood]

Fixes #2773

When separate-pull-requests: true is set, updating an existing release PR consistently fails with:

Validation Failed: {"resource":"PullRequest","code":"custom", "message":"A pull request already exists for ..."}

The branch is updated successfully (Updating reference heads/release-please--branches--main--components--<comp>), but the action exits non-zero.

Reproduces on release-please-action@v4 and @v5, against library 17.3.0 and 17.6.0, with a GitHub App token.

Root cause

GitHub.updatePullRequest (and LocalGitHub.updatePullRequest) was reusing code-suggester.createPullRequest to do both the branch push and the PR refresh. code-suggester always:

1. pushes the branch,
2. looks up an existing PR for that branch via octokit.pulls.list({head}) plus a strict pr.head.label === head find,
3. if not found, calls octokit.pulls.create.

The lookup in step (2) is best-effort. It can miss the PR for several reasons, case-sensitivity differences between repository.owner (sometimes lowercased through env-var paths like GITHUB_REPOSITORY) and the org login as GitHub returns it in pr.head.label, the un-paginated single-page response, brief eventual consistency on pulls.list. When the lookup misses, step (3) runs and GitHub returns 422 because there's obviously already a PR for that branch.

release-please already knows the PR number it's updating, manifest.ts:1040 matched the existing PR before calling updatePullRequest. So the detect-or-create step is unnecessary work that can fail. Only the create path actually needs find-or-create semantics; the update path was misusing code-suggester.

The bug surfaces especially under separate-pull-requests: true because each component's body diverges independently after a new commit, and every divergent body hits the update path.

Fix

• Add a new low-level primitive commitAndPushChanges(branch, message, changes) to GitHubApi. It uses the Git Data API directly: getRef → getCommit → createBlob (per file) → createTree → createCommit → updateRef --force. No PR detection. No PR create. Empty change sets are a no-op.
• GitHub.updatePullRequest and LocalGitHub.updatePullRequest now call commitAndPushChanges followed by the existing gitHubApi.updatePullRequest(number, title, body) PATCH.
• code-suggester is no longer touched in the update path, so octokit.pulls.create cannot be called and the 422 cannot occur, regardless of how the upstream lookup would have behaved.
• The create path (GitHub.createPullRequest) is unchanged. "Find-or-create" is the correct semantic there; only the reuse in the update path was wrong.

Test plan

• npm run compile, passes
• npm run lint, clean (only pre-existing warnings in unrelated files)
• npm test, full suite (1101 tests) passes

You can test the fix by using my release-please-action fork.

#...
steps:
  - uses: Kerwood/release-please-action@main
    with:
      # this assumes that you have created a personal access token
      # (PAT) and configured it as a GitHub action secret named
      # `MY_RELEASE_PLEASE_TOKEN` (this secret name is not important).
      token: ${{ secrets.MY_RELEASE_PLEASE_TOKEN }}
      # optional. customize path to release-please-config.json
      config-file: release-please-config.json
      # optional. customize path to .release-please-manifest.json
      manifest-file: .release-please-manifest.json

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Kerwood]

I believe this PR aligns well with the future plan to remove code-suggester as a dependency in this project, since it implements its own commitAndPushChanges function and uses that in place of code-suggester. #2770

@chingor13 Any chance you've had time to look at this PR?