fix: use PR base branch as sourceBranch to support non-default branch backports

[larryng-rapyuta]

Problem

The backport library's getOptionsFromGithub() fetches .backportrc.json from the repo's default branch (via the GithubConfigOptions GraphQL query which uses defaultBranchRef). This means sourceBranch is always read from the default branch's config.

When a PR targets a non-default branch (e.g. release/2.10), the sourceBranch from the default branch config (e.g. "devel") doesn't match the PR's actual base branch, causing the backport to abort with:

"There are no branches to backport to. Aborting."

This was observed on rr_oks#11525 — a PR merged to release/2.10 with backport-to-release/2.9 label. The backport action ran successfully but aborted because it read sourceBranch: "devel" from the default branch config instead of using release/2.10.

Even though release/2.10 has its own .backportrc.json with sourceBranch: "release/2.10", the library never reads it.

Fix

Extract the PR's base branch from the GitHub event payload (context.payload.pull_request.base.ref) and pass it via processArgs (['--sourceBranch', prBaseBranch]), which has the highest precedence in the backport library's option merging chain:

defaultConfigOptions < optionsFromConfigFiles < optionsFromGithub < optionsFromCliArgs (processArgs)

This ensures sourceBranch always matches the actual base branch of the PR, regardless of which branch's .backportrc.json the library reads.

Changes

• src/run.ts: Extract PR base branch and pass as --sourceBranch via processArgs
• src/run.test.ts: Updated existing test, added new test for non-default branch scenario
• dist/index.js: Rebuilt bundle

Testing

All 8 tests pass:

PASS src/run.test.ts
  run
    ✓ calls backport with correct arguments
    ✓ passes PR base branch as sourceBranch via processArgs for non-default branches
    ✓ aborts if no targetBranches, branchLabelMappings or autoBackportLabelPrefix are provided
  getFailureMessage
    ✓ should return empty when there are no unhandled errors
    ✓ ignores handled errors
    ✓ returns unhandled errors
    ✓ should error message (failure)
    ✓ should error message (aborted)