[FEA] Add /merge command workflow

[NvTimLiu]

Summary

Add a bot-driven /merge workflow so an authorized developer can request a pull request merge by posting an exact /merge issue comment. The request should remain pending until every repository merge requirement is satisfied, then squash-merge the current PR head automatically.

This removes the manual timing window after CI and approvals complete, during which another merge or dependency/submodule update can make the PR stale and require another CI cycle.

Goals

• Allow an authorized developer to request /merge before or after CI completes.
• Merge automatically as soon as all repository merge requirements are satisfied.
• Preserve squash merge as the default for normal PRs.
• Use the same authorization boundary as manual merging.
• Keep branch protection, required reviews, required checks, CODEOWNERS, and rulesets as the source of truth.
• Provide an observable audit trail for queued, blocked, merged, and rejected requests.

Command handling

• Accept /merge only when it is the complete issue-comment body after trimming whitespace.
• Ignore or reject extra text, inline code, edited comments, review comments, and PR descriptions.
• Record the repository, PR number, requester, request time, and merge method.
• Keep any bot status comments informational; they must not change merge eligibility.

Authorization

• Only users who could merge manually may request /merge; initially require write or admin permission.
• Check authorization when the command is created and again immediately before merging.
• Do not queue unauthorized requests.
• Make unauthorized attempts visible through a comment, check, or audit log.

Merge eligibility

Before merging, verify:

• The PR is open and not a draft.
• Required checks pass for the current PR head.
• Required reviews and CODEOWNERS rules are satisfied.
• No unresolved CHANGES_REQUESTED review exists from a user with write, admin, or owner access.
• The PR has no merge conflicts.
• The target branch is allowed.
• Required labels are present and configured blocking labels such as DO NOT MERGE are absent.
• All repository-specific CI, dependency, integration, and submodule-consistency checks pass.

Pending and failed requests

• Keep a valid request pending while any required condition is incomplete, missing, failing, conflicting, or stale.
• If new commits are pushed, reevaluate all requirements against the new current head before merging.
• Honor stale-approval dismissal and latest-head review/check rules exactly.
• Require a new command only after rejection, cancellation, supersession, or close/reopen.
• On conflicts or missing policy conditions, report the blocker and leave the request pending.
• Retry transient GitHub API errors with bounded backoff.
• Never retry indefinitely without exposing the current blocker.

Merge execution

• Squash-merge normal PRs.
• Use the evaluated current head SHA as a race guard.
• Use the squash title <PR title> (#<PR number>).
• Include the PR description or configured source, authors, approvers, and PR URL in the commit body.
• Remove square brackets from commit titles if matching the cuDF/RAPIDS convention exactly.
• Leave a final comment or GitHub timeline event that makes the merge actor and commit discoverable.

/merge nosquash

• Reject /merge nosquash on normal feature and bug-fix PRs.
• Allow it only for explicitly enabled and separately documented release forward-merge branch patterns.

Security

• Use least-privilege credentials.
• Do not check out or execute PR code while processing comments.
• Prevent untrusted fork code from influencing authorization, particularly with issue_comment or pull_request_target.
• Honor GitHub protections rather than duplicating them incompletely.
• Log requester, SHA, eligibility result, merge attempt result, and failure reason.
• Do not allow self-approval or self-merge unless existing repository policy permits it.
• Preserve the existing trust and CI-approval process for forked PRs.

Reevaluation events

Reevaluate a pending request after:

• /merge comment creation
• PR synchronize or force-push
• Ready-for-review transition
• Review submission, dismissal, or update
• Check run, check suite, or status completion
• Label addition or removal
• Base-branch change
• Relevant branch-protection or ruleset changes, when exposed
• Scheduled safety retry after transient failures

Repository requirements

• Add or enable the repository-level bot configuration.
• Keep release, integration, shim, dependency, and submodule checks required.
• Do not merge dependency or artifact updates until downstream CI passes for the final PR head.
• Document /merge in CONTRIBUTING.md or .github/PULL_REQUEST_TEMPLATE.md.

Why native GitHub auto-merge is insufficient

Native auto-merge covers the core checks/reviews/squash workflow, but it does not provide:

• Exact /merge command parsing and auditing
• Required or blocking label policy without a custom required check
• Persistence after all external-contributor pushes or base-branch changes
• Custom blocker reporting and retry behavior
• Automated RAPIDS-style commit metadata generation
• Conditional /merge nosquash behavior
• A bot-only normal merge path with a documented emergency bypass

Acceptance criteria

• An eligible PR is squash-merged after an authorized exact /merge comment without further human action.
• A request submitted while CI is running remains queued until all requirements pass for the current head.
• New commits trigger reevaluation and cannot merge using stale checks or approvals.
• Active change requests and merge conflicts prevent merging and expose the blocker.
• Unauthorized or malformed commands do not queue a merge.
• Successful merges use the configured title/body format and retain an auditable record.