Renaming a stacked branch with `git branch -m` strands the stack: metadata keeps the old name

Comece em cmd/utils.go com o erro do branch atual e, em seguida, rastreie resolveStack, FindAllStacksForBranch e Stack.Contains em internal/stack/stack.go. Revise o uso de git.BranchExists e o tratamento de renomeações em internal/modify/apply.go, incluindo o reparo baseado no reflog descrito na issue. O trabalho estará concluído quando um branch renomeado externamente for diagnosticado e puder ser reparado ou removido sem exigir um número de stack.

Summary

gh stack matches the current branch against .git/gh-stack by exact string
(resolveStack → FindAllStacksForBranch → Stack.Contains, cmd/utils.go:395,
internal/stack/stack.go:241). Renaming a stacked branch with git branch -m is not
observed, so the stack file keeps pointing at a name that no longer exists and every
stack command bails out with the same generic message.

gh stack modify already renames a branch in git and in the stack file together
(internal/modify/apply.go:190-228, verified: both .git/gh-stack and the git branch are
updated), so the invariant is understood. This issue is about a rename performed outside
gh-stack, which is how most people rename a branch.

Related but distinct: #137 reaches the same stranded state through sync --prune
(branch deleted, stack entry left behind), and #193 is the same family of "git operations
performed outside gh-stack aren't observed".

Reproduction

Requires an origin remote, but the repository need not exist.

git init repro && cd repro
git commit --allow-empty -m initial
git remote add origin https://github.com/you/does-not-exist.git
git switch -c feat/test
git commit --allow-empty -m wip

gh stack init feat/test      # ✓ Adopted 1 branch: main ← feat/test
gh stack view --short        # ✓ works

git branch -m feat/test-1

gh stack view                # ✗ broken from here on

gh stack init with no arguments errors with "interactive input required", so the branch
name is passed explicitly to keep the repro scriptable.

Observed

.git/gh-stack is byte-identical before and after the rename; it still records
"branch": "feat/test".

gh stack unstack <n> --local would remove the entry, but a stack that has not been
submitted has no stack number (Number int \json:"number,omitempty"``,
internal/stack/stack.go:46), so it cannot be targeted:

$ gh stack unstack 1 --local
✗ stack #1 is not tracked locally

With no gh stack list (#150) and an interactive-only checkout picker, the ways out are
renaming the branch back (verified: this fully restores the stack) or editing
.git/gh-stack by hand.

Expected

1. Diagnose instead of denying. Before printing "is not part of a stack"
   (cmd/utils.go:234-243), check whether a recorded stack references a branch that no
   longer exists. git.BranchExists is already used throughout (cmd/sync.go:413,
   cmd/modify.go:315, …). checkout should also stop surfacing git's raw
   pathspec ... did not match error.

2. Leave an escape hatch. Removing or repairing a stack whose branches are missing
   should not require a stack number — this is the part #137 also runs into.

3. Offer to repair. git records the rename in the reflog:

   feat/test-1@{0}: Branch: renamed refs/heads/feat/test to refs/heads/feat/test-1
   

   so the stack file can be updated after confirming with the user. Reflog entries expire,
   so this complements 1 rather than replacing it.

I have a patch implementing 1 and 3 and will open a PR referencing this issue.

Environment

• gh stack v0.1.0
• macOS 24.6.0 (Darwin, arm64)