gh stack rebase replays the same child commit twice on v0.1.1

## Summary

`gh stack rebase` appears to replay the same child commit twice when a lower
branch in a stack receives a new commit.

This reproduces consistently for me with `gh stack` v0.1.1 on a freshly
created stack.

This looks similar to #250, but I am reproducing it on v0.1.1, which includes
the fix for amended parent commits being replayed into child branches.

## Environment

- OS: Windows
- Shell: PowerShell
- `gh stack version`: 0.1.1
- Stack trunk: `main`

## Stack

I created a simple three-layer stack:

main
└─ stack3/01-model
└─ stack3/02-service
└─ stack3/03-api

Each layer initially has one commit:

- `stack3/01-model`: Add Product model
- `stack3/02-service`: Add Product Service
- `stack3/03-api`: Add Product API

I then added another commit to the bottom layer (`stack3/01-model`).

Conceptually:

main
└─ Add Product model
└─ Add price to Product model
└─ [Product Service should be rebased here]
└─ [Product API should be rebased here]

## Reproduction

After adding the new commit to `stack3/01-model`, I ran:

gh stack rebase

Output:

Fetched latest main from origin
Trunk main is already up to date
Stack detected: (main) <- stack3/01-model <- stack3/02-service <- stack3/03-api
Rebasing branches in order, starting from stack3/01-model to stack3/03-api
Rebased stack3/01-model onto main

The command then stops while rebasing `stack3/02-service`.

From another terminal:

git status

reports:

interactive rebase in progress; onto 9c2c2c2

Last command done (1 command done):
pick 96bd07c # Add Product Service

Next command to do (1 remaining command):
pick 96bd07c # Add Product Service

You are currently rebasing branch 'stack3/02-service' on '9c2c2c2'.
(all conflicts fixed: run "git rebase --continue")

Changes to be committed:
new file: src/product-service.js

I inspected the rebase state.

`git rebase --edit-todo` contains:

pick 96bd07c # Add Product Service

And:

Get-Content .git\rebase-merge\done

contains:

pick 96bd07c... # Add Product Service

Therefore the same commit (`96bd07c`) appears to have already been processed
and is also still present as the next commit in the rebase todo.

## Actual behavior

The cascade rebase gets stuck while rebasing the second layer.

The same `Add Product Service` commit appears as both:

- the last completed rebase command, and
- the next remaining rebase command.

`src/product-service.js` is already staged from the first application.

## Expected behavior

Each layer's own commit range should be replayed exactly once onto the newly
rebased parent.

Conceptually, after changing the bottom layer:

main
└─ model
└─ model-update
└─ service'
└─ api'

The service commit should be replayed once onto the new `01-model` head, and
the API commit should then be replayed once onto the new `02-service` head.

## Additional notes

I previously encountered a similar failure with another stack. To rule out
corrupted state from that experiment, I created `stack3` from scratch and
reproduced the problem again.

I also confirmed that the installed extension is current:

gh stack -v
gh stack version 0.1.1

gh extension upgrade github/gh-stack
[stack]: already up to date

This looks related to #250, but that issue reproduced on v0.0.8 and the
release notes indicate that amended-parent replay behavior has since been
fixed.

Happy to provide the repository or additional `.git/gh-stack` / rebase
metadata if useful.

Start at the `gh stack rebase` command and reproduce the three-layer stack described in the issue on Windows or PowerShell. Inspect the cascade rebase state for `stack3/02-service`, including `.git/rebase-merge/done` and `git rebase --edit-todo`. Done means each layer's own commit range is replayed exactly once and the API layer rebases successfully onto the updated service layer.

Vom Indexierungsmodell aus dem Issue-Text verfasst.