investigate `git rebase --update-refs`

[boneskull]

Refs: blog post, Git docs

git rebase --update-refs may simplify our rebase operations considerably. Investigate where it may be applicable and enumerate advantages & disadvantages (if any).

git rebase --update-refs first appeared in Git v2.38 (2022); this is not a concern. Current macOS dev tools provide Git v2.50.1. The minimum Git version should be noted in README.md.

Note that a user can configure Git to always use --update-refs via git config rebase.updateRefs true. Unlikely, but if it turns out --update-refs will screw up our operations, we would need to supply --no-update-refs to any rebase operations.

[boneskull]

Investigation summary

Spike complete. Full analysis lives at docs/update-refs.md (added in the PR that closes this issue). Highlights:

Recommendation

Opportunistic opt-in in the existing per-branch loop, with explicit --no-update-refs when --worktrees mode is active. Defer the larger leaf-path rewrite to a follow-up issue.

Key findings (from experiments against Git 2.54)

1. Linear chain works perfectly. git rebase --update-refs <trunk> from the leaf updates every intermediate branch in one shot. Git emits a clean "Updated the following refs" summary.
2. Branching trees still need one rebase per leaf path. Sibling refs are correctly left alone. Leaf-path rewrite scales as O(leaves), not O(branches).
3. --onto plays nicely. When we use git rebase --onto <newBase> <oldBase> (our fork-point flow after squash merges), refs outside the rebased range stay put. The existing fork-point logic remains correct.
4. Worktree collision is a footgun. When an intermediate branch is checked out in a linked worktree, git silently skips updating that ref and leaves the stack broken (the rebased descendant no longer reaches the unmodified intermediate). No warning, no non-zero exit code. Any adoption of --update-refs must suppress the flag (or refuse the operation) when --worktrees mode is active.
5. Mid-chain conflicts are safe. Refs are moved atomically at the end of the rebase. Aborting mid-conflict needs no extra ref-restoration work.
6. Untracked sibling refs get moved too. Documented behavior; document and move on.
7. rebase.updateRefs = true global is safe with the existing per-branch loop. Confirmed @boneskull's empirical observation. Each iteration emits "skipped previously applied commit" advisory noise but produces the correct final SHAs.

Minimum Git version

--update-refs shipped in Git 2.38 (Oct 2022). Already documented in README.md as part of this PR.

Follow-up

Filing a separate issue for the leaf-path rewrite (one rebase per leaf instead of one per branch). That's a bigger change touching cmd/restack.go, cmd/continue.go, the cascade state file, and e2e coverage.

[boneskull]

Follow-up issue for the leaf-path rewrite filed: #118.