Rebase replays a parent's commits when a branch's recorded base is stale

[gavinsan33]

When a branch's recorded base is an older copy of its parent, gh stack rebase and sync replay the parent's commits onto their own newer copies. git rebase --onto <new> <old> only skips commits whose patch is already in <old>, so each replayed commit conflicts wherever the parent changed it later. Each of those conflicts has only one right answer, which is to keep the new base's version. In one of my stacks, a rebase replayed 61 commits, and 53 of them were copies already in the parent.

I have a fix on my fork: rebase-drop-applied-commits. I couldn't open a PR because PR creation seems limited to collaborators.

• When a rebase stops on a commit HEAD already contains (as an ancestor, or by patch ID, the test git rebase itself uses to skip cherry-picks), it skips that commit and continues. This sits next to the rerere auto-continue in tryAutoResolveRebase, so it covers rebase, sync, modify and --continue, in origin and linked worktrees.
• Each drop is reported as Dropped <sha> <subject>: already in the new base through a new optional RebaseOpts.Notify.
• A copy whose patch changed is not treated as applied, so its conflict still stops, as do conflicts in the branch's own commits.

There are two tests. TestRebase_DropsCommitsAlreadyInParent is a real-Git regression of a child recorded on an outdated parent, and it fails without the change. TestIntegration_RebaseDropsCommitsAlreadyInBase checks that a same-patch copy is dropped and a changed-patch copy still stops. go vet and the full scripts/test suite pass. I'm happy to open it as a PR if a maintainer can enable that.