After a fork's pull lands in slices, the author's `git merge main` is clean, proven with two forges #9054

Adds test/pull-slices-two-forges.test.ts, which shows end to end with two forges that a fork's author can still merge main cleanly after their pull lands in slices. The test passes against the current slice code, so nothing under src/ changed.

How it's set up:

• Forge A has alice/app.
• Forge B has bob/app, created by pushing A's history into it, so it is a fork of A's repository.
• The author's clone has three remotes: B as origin, A's main, and the author's fork on A that the pull comes from. A cross-forge "propose upstream" pull would be a branch of A's own repository, and slicing refuses those with not_fork, so the pull has to come from a fork on A.

First test:

• The author pushes x, y and z, and A moves on with a commit of its own so each slice is a real merge.
• A lands the pull in two slices: up to y, then the head z.
• It checks that the first slice's merge commit has y itself as its second parent.
• The author makes one more local commit and runs git merge of A's main. The test requires every one of their commits to be an ancestor of main, the merge to be a clean two-parent merge, and z's change to appear exactly once in history (not copied by a squash or rebase).
• The merged result is pushed back to B without a force.

Second test (the failure case): it builds a squashed main and a rebased (cherry-picked) main and shows that the same author-side check reports "not an ancestor" for both. So the first test would fail if a slice ever rewrote the author's commits.

The repositories hold one file per commit; the file runs in about 3 s. bun scripts/gate.ts and bun x tsc --noEmit are clean, and both tests pass.

Not done: the issue asked for a keep_plan tool, but this run didn't have one, so no plan was kept on the issue. No docs changed.

🤖 Generated with Claude Code

Closes #9043

Adds test/pull-slices-two-forges.test.ts, which shows end to end with two forges that a fork's author can still merge main cleanly after their pull lands in slices. The test passes against the current slice code, so nothing under src/ changed.

How it's set up:

• Forge A has alice/app.
• Forge B has bob/app, created by pushing A's history into it, so it is a fork of A's repository.
• The author's clone has three remotes: B as origin, A's main, and the author's fork on A that the pull comes from. A cross-forge "propose upstream" pull would be a branch of A's own repository, and slicing refuses those with not_fork, so the pull has to come from a fork on A.

First test:

• The author pushes x, y and z, and A moves on with a commit of its own so each slice is a real merge.
• A lands the pull in two slices: up to y, then the head z.
• It checks that the first slice's merge commit has y itself as its second parent.
• The author makes one more local commit and runs git merge of A's main. The test requires every one of their commits to be an ancestor of main, the merge to be a clean two-parent merge, and z's change to appear exactly once in history (not copied by a squash or rebase).
• The merged result is pushed back to B without a force.

Second test (the failure case): it builds a squashed main and a rebased (cherry-picked) main and shows that the same author-side check reports "not an ancestor" for both. So the first test would fail if a slice ever rewrote the author's commits.

The repositories hold one file per commit; the file runs in about 3 s. bun scripts/gate.ts and bun x tsc --noEmit are clean, and both tests pass.

Not done: the issue asked for a keep_plan tool, but this run didn't have one, so no plan was kept on the issue. No docs changed.

🤖 Generated with Claude Code