gh stack modify --continue hides subsequent rebase conflict details

Start at the gh stack modify --continue conflict-recovery path and compare it with the initial gh stack modify conflict reporting. Reproduce the multi-conflict sequence described in the issue, including staging the first resolution, then verify that the next conflict shows the branch, conflicted files, progress, and resolve/stage/continue instructions instead of only the exit status.

Description

When gh stack modify --continue advances an in-progress rebase and encounters another conflict, it prints only:

✗ rebase continue failed — resolve remaining conflicts and try again: exit status 1

It does not show:

• Which branch is being rebased
• Which files conflict
• Rebase progress
• The usual resolve/stage/continue instructions

The initial gh stack modify conflict reports this information correctly. Subsequent conflicts reached through --continue do not.

Reproduction

1. Create a stack where dropping or moving a lower branch causes conflicts in multiple downstream commits.

2. Run gh stack modify.

3. Apply the structural change.

4. Resolve the first conflict.

5. Stage the resolved file:

   git add <file>
   

6. Continue:

   gh stack modify --continue
   

7. Let the rebase encounter another conflict.

Actual result

Only the generic exit-status message appears:

✗ rebase continue failed — resolve remaining conflicts and try again: exit status 1

The user must separately run:

git status
git diff --name-only --diff-filter=U

to discover that another conflict appeared and identify its files.

Expected result

gh stack modify --continue should report the next conflict like the initial modify operation:

Conflict rebasing <branch>

Conflicted files:
  <file>

Resolve the conflicts, stage with `git add <file>`, then run
`gh stack modify --continue`.

Progress for successfully completed branches or commits should also remain visible.

Environment

• gh 2.97.0
• gh-stack 0.1.0
• macOS 26.6

Additional context

This appears distinct from #146. No merged or pruned branch lookup is involved at this stage; the modify operation is already in conflict recovery and --continue reaches another conflicting commit.