sync: retarget upstack PRs on forge after deletion

[ed-irl]

When gs repo sync deletes branches whose PRs were merged,
upstack PRs on the forge are left targeting deleted branches.
This causes confusion on platforms like GitHub, where the PR
base no longer matches the local stack state.

This change retargets surviving upstack PRs on the forge to
their nearest surviving ancestor (or trunk if none exists)
after sync deletes merged branches. Cyclic base chains fall
back to trunk to avoid infinite loops.

Covered by unit tests for candidate collection and ancestor
resolution, plus test scripts exercising single-merge and
deep-stack scenarios end-to-end.

Regarding this question on #1073:

So just to clarify/confirm the behavior:
git-spice already retargets upstack branches when their bases are deleted, but it does so entirely locally.
The focus of this change is to specifically also update the forge?
The next submit for those branches would also update the base branch in the forge.
I would appreciate some more context on what issue we're running into here.
(Context on my hesitance: repo sync is currently read-only for the forge. This would add a write, so I want to make sure we have a good reason to.)

The issue encountered is branch corruption when adding the gs bm command - which I will post later today on this stack. Prior to the merge command, the forge itself drove merge events and the sync/submit cycle pulled merge changes and drove repointing based on merges that happened elsewhere. When I added the gs bm command the flow was flipped, and the stack would become corrupted if you merged anything besides the bottom branch. I'll post a ref to that PR when I post it. It took me a minute to remember what had been happening and I needed claude to help me figure it out again 😂 . It provided this somewhat more verbose explanation:

Before gs branch merge, gs read forge merge state and reconciled local — that's the read-only pattern you're describing, and repo sync was fine being one-way (forge → local). The next submit falling back to fix the forge base was fine because nothing else gs did was authoritative over forge merges.

gs branch merge (in a separate PR in this stack) breaks that assumption. It writes merges to the forge and then reacts to those merges by mutating local state (deletes branches, reparents upstack). That makes the forge↔local invariant load-bearing inside gs bm, not just at "next submit" time. Concretely, a stack of A → B → C where A was squash-merged externally and you then run gs bm C will silently bring A's pre-squash commits back into main via B's merge, because B's remote branch still contains them and gs has no way to know B should be rebased first.

PR #1073 is the other half of that contract: when repo sync rebases B locally, also retarget B's forge PR base so the forge and local agree on what B's parent is. Without it, gs is making local decisions (rebases, reparents) that the forge isn't told about, and the next forge-driven operation (review, or another gs bm) sees an inconsistent world.

[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 ◀
    • 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.}

[ed-irl]

Attempted to rename via gh rename api - but wound up closing. Attempting a push-then-repoint-then-delete workflow instead.