Partial stack merge dismisses approval on the next PR even though its diff is unchanged

[GPHemsley-RELX]

Summary

After a partial stack merge, GitHub's automatic rebase of the next PR dismisses that PR's approval with "The merge-base changed after approval.", even though the rebased PR's diff is unchanged.

The repository uses rebase merges and has Dismiss stale pull request approvals when new commits are pushed enabled. Both are standard settings, but this combination may not be covered by testing.

The merging docs say Rebase stack keeps approvals when the diff hasn't changed, even with stale-approval dismissal enabled. The automatic rebase after a partial merge doesn't seem to follow the same rule.

Steps to reproduce

1. Use a repository that allows rebase merging and dismisses stale approvals.
2. Create a stack: main ← A ← B.
3. Approve B.
4. Merge only A on github.com, using rebase merge.
5. Let GitHub automatically rebase B onto main and retarget it.

Expected

B's approval is kept because its diff hasn't changed.

Actual

Within seconds of A merging, GitHub force-pushes B and dismisses its approval with "The merge-base changed after approval." B's diff against its base before the rebase matches its diff against main afterward: same commit count, files, and patches.

As a result, every PR above a partially merged layer needs re-approval, even when nothing in it changed.

Possibly related: #174, a partial merge that invalidated a latest-push approval.