ci: add fork PR support to /rebase workflow

[waveywaves]

Changes

Replace the hard fork rejection ("Cannot rebase PRs from forks") with fork detection and maintainerCanModify validation. Fork PRs are now rebased by checking out the fork repo, adding upstream as a remote for the base branch, performing the rebase, and pushing back to the fork with --force-with-lease.

This mirrors the fork support already implemented in the /squash workflow (_squash-command.yaml from PR #3173), using the same pattern:

• Checkout the fork repo directly (origin = fork)
• Add upstream remote for the base branch
• Rebase onto upstream/<base> instead of origin/<base>
• Push to origin (which is the fork)

Fork PRs require the author to enable "Allow edits from maintainers" in the PR settings. If disabled, the workflow posts an actionable error message asking the author to enable it. Same-repo PR behavior is completely unchanged.

Motivation: All fork-based contributions (e.g., PRs #9366, #9367, #9368 on tektoncd/pipeline) currently cannot use /rebase, forcing manual rebases. This is especially painful when multiple PRs need rebasing after dependency bumps land on main.

/kind feature

Submitter Checklist

• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign anithapriyanatarajan after the PR has been reviewed.
You can assign the PR to them by writing /assign @anithapriyanatarajan in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[waveywaves]

cc @afrittoli @anithapriyanatarajan

[anithapriyanatarajan]

@vdemeester @waveywaves — IMHO a merge queue would address the core pain point here better than a /rebase bot. The main motivation cited is keeping PR branches current with main after dependency bumps - merge queue handles that automatically at merge time. Combined with contributors owning their own rebases during review (as they would with any Git workflow), I'm not sure the added complexity of bot-driven fork rebasing is justified. Happy to discuss.

[waveywaves]

@anithapriyanatarajan we already have a /rebase bot which works well in the pipeline repo, helps with rebasing the cherry pick PRs and branches created on the origin remote. This PR helps speed up merging contributor PRs if they are already in good shape and if the contributor just has to rebase them and the /rebase helps us do this with the Tekton Bot itself instead of having the maintainer coauthorship on the commit if you would want to make changes to the fork yourself which we ideally musnt do. Commands like these help us follow the process as well while keeping the feedback loop efficient.