fix: resolve BranchOnto target from git ref, not stored state

[ed-irl]

When BranchOnto moved a non-trunk target, it used the target branch's
stored Head hash to rebase the moved branch. This stored value could
be stale within a single transaction — for example, when branch onto
restacks upstack branches after moving the target, each subsequent
rebase saw the pre-move hash rather than the branch's actual ref.

Resolve the target by peeling its git ref instead, which always
reflects the current state. The tracked-branch check is preserved for
non-trunk targets, but the hash itself now comes from the ref.

This issue is similar to #1150 - the gs bm command will introduce the possibility of iterative changes to the stack structure during command execution, so there's a need to re-read refs during command execution.

I also had some issues remembering why exactly we needed this. Claude had this somewhat more verbose explanation:

This is a defensive consistency fix in BranchOnto. Before: the target hash was resolved from the git ref when the target was trunk, but from LookupBranch(...).Head when non-trunk. Even though both paths ultimately route through PeelToCommit, the two-source pattern made BranchOnto's behavior sensitive to small state/ref desynchronization windows that show up in chained BranchOnto calls (stack edit, delete-with-upstack-reparent, gs bm's cleanup loop).

The fix collapses both to PeelToCommit and uses LookupBranch only as a tracking-check for non-trunk targets. The intent is that BranchOnto's rebase target is always exactly what git currently says — no transient stored-state path can produce a stale hash.

This surfaced while developing gs branch merge, which calls BranchOnto indirectly through gs branch delete for upstack reparenting after each merge in the plan. The corruption symptom there was hard to reproduce in isolation because it requires a partial-stack merge whose surviving base isn't trunk.

[skip changelog]: bug fix only

[ed-irl]

This change is part of the following stack:

• submit: Check base CR status before submission #1154
  • sync: retarget upstack PRs on forge after deletion #1150
    • fix: resolve BranchOnto target from git ref, not stored state #1151 ◀
      • Add 'downstack merge' command to merge stacks #1152
        • feat: add 'gs ci merge-guard' to block out-of-order stacked PR merges #1153

_{Change managed by git-spice.}

[abhinav]

I'm not sure this is right. The premise in the PR message is false.
LookupBranch does not use a recorded Head commit hash. Only the base hash uses recorded values:

We load storage information and current PeelToCommit:

git-spice/internal/spice/branch.go

Lines 107 to 109 in 7fbfdaf

	func (s *Service) LookupBranch(ctx context.Context, name string) (*LookupBranchResponse, error) {
	resp, storeErr := s.store.LookupBranch(ctx, name)
	head, gitErr := s.repo.PeelToCommit(ctx, name)

Then we put that directly in the response:

git-spice/internal/spice/branch.go

Lines 143 to 147 in 7fbfdaf

	out := &LookupBranchResponse{
	Base: resp.Base,
	BaseHash: resp.BaseHash,
	UpstreamBranch: resp.UpstreamBranch,
	Head: head,

So I think this might've been a speculative fix for something else that went wrong?