push_to_pull_request_branch: recognize a merged base commit that is behind the current base tip in bundle validation #69912

Summary

Since #68459 / #68806, unsigned bundle pushes from push_to_pull_request_branch measure size and protected files against a merge-tree of the old PR head and the current base-branch tip (resolved with git ls-remote when the safe-outputs job runs). If the agent merged the base branch and the base branch advanced before the safe-outputs job started, the merged base commit is no longer the tip, getBundleValidationBase falls back to PR-head validation, and all of the base-branch changes since the PR last synced count toward max-patch-size.

Why this matters

The agent merges the base branch during its run, but publishing happens later, after the agent job finishes and the safe-outputs job starts. On a busy repository the base branch routinely moves in that window. In our repository the default branch takes roughly one merge every 20-25 minutes (130 first-parent commits in 48 h), and one day of default-branch changes is about 22 MB of git diff --binary, above the schema maximum of max-patch-size (10240 KB). So whenever the race is lost, the push is rejected however small the agent's own change is, and raising the limit cannot help.

The agent cannot avoid this: the push_to_pull_request_branch tool takes no input for the base commit it merged (additionalProperties: false), and per #68806 agent metadata and workflow-start SHAs rightly do not establish provenance.

Proposal

Keep the trusted tip from ls-remote as the only source of provenance, but accept any base-branch commit reachable from that tip that the candidate newly incorporates:

1. From the bundle history (<old head>..<candidate>), collect merge parents that are not ancestors of the old head (candidate base commits the agent merged).
2. Confirm that one of them is an ancestor of the trusted tip without fetching objects, e.g. with the REST compare API (GET /repos/{owner}/{repo}/compare/{commit}...{tip}, status of behind or identical), which keeps validation metadata-only as Make PR bundle history recovery explicit and validation offline #68806 intends.
3. Use the newest confirmed commit in place of the tip for getBundleValidationBase (merge-tree with the old head, conflicted paths, agent-history exclusions); fall back to PR-head validation exactly as today when none is confirmed.

This keeps every existing check (patch size, expanded changed-content size, protected files, octopus rejection) and only changes which trusted base commit is recognized.

Version

Observed by reading actions/setup/js/push_to_pull_request_branch.cjs at v0.92.5 (resolveTrustedBaseTip, getBundleValidationBase). We currently work around it on v0.89.21 with a runtime patch of the handler and would like to drop that patch.