fix(merge): git replay takes --advance, not flags it never had

performRebase invoked git replay --ref-action=print --onto=<sha> --ref=refs/heads/<base>. Neither --ref-action nor --ref has ever existed in git's replay (git replay ([--contained] --onto <newbase> | --advance <branch>) <range> is the whole surface). The first invocation died on --ref-action, the unknown-option fallback retried without it, and the retry died on --ref — so every rebase-strategy merge has failed since the strategy was written.

The comment above the call believed some git versions apply the ref update themselves unless asked to print. Replay has never applied anything — printing update <ref> <new> <old> lines is all it does — so the guard the flag was protecting was never at risk. --advance refs/heads/<base> is the real spelling: the existing stdout parser and the guarded update-ref work on its output unchanged, including the refusal when the base moved mid-merge (the commits get built on the moved tip, the guard sees the old value it expected is gone, and refuses — the same answer the other strategies give).

tests/unit/merge-apply.test.ts goes from 11/13 to 13/13. The two rebase cases that passed before did so vacuously: an untouched branch has nothing to collapse, and the moved-base case expected failure, which wrong flags also deliver.

🤖 Generated with Claude Code