rebase discards a still-valid recorded base after the parent's history is edited, replaying the parent's old commits

(This issue was AI generated but I have reviewed it, understood it, and I'm accountable for its content.)

**Version**: gh-stack v0.1.0.

**Setup**: trunk `main`; stack `A ← B` (`gh stack init A B`); `A` has commit A1 modifying `f.txt`, `B` has commit B1 adding `g.txt`.

**Repro**: amend A1 on `A` (change `f.txt`, keep the message), then `gh stack rebase`.

**Expected**: `B` is rebased by replaying only B1 onto the amended `A` — B's recorded base (old A tip) is still an ancestor of `B` and delimits exactly B's own commits.

**Actual**: the recorded base is discarded (apparently because it is no longer in `A`'s history), the boundary falls back to `merge-base(A, B)` — *below* the amendment — and the old A1 is replayed onto the amended `A`: a bogus conflict in `f.txt`.

**Worse variant (silent corruption)**: if the amendment only *removes* part of A1 (e.g. A1 touched `f.txt` + `extra.txt`, and the amend drops the `extra.txt` change), the old A1 replays cleanly: `B` ends up with a duplicated commit and the removed `extra.txt` resurrected — reported as success.

**Suggested fix**: accept a recorded base as the `--onto` boundary whenever it is an ancestor of the branch being rebased; membership in the parent's current history should not be required. This matches Graphite's restack semantics and is what makes stacks robust under history editing.

The same failure triggers when the *trunk*'s history is edited (e.g. a commit below the stack is amended via fixup): the whole old trunk segment is replayed into the bottom stack branch.

The payload names no implementation files or tests. Start at the `gh stack rebase` entry point and reproduce the amended-parent case, then trace how the recorded base is accepted or discarded. Done means B replays only B1 after parent or trunk history edits, including the silent-corruption variant, with regression coverage for both cases.

索引モデルが issue の本文から書いたものです。