Add 'downstack merge' command to merge stacks

[ed-irl]

Summary

This adds gs downstack merge as an experimental command
for merging a stack of Change Requests bottom-up through the forge API.

The command acts as a local merge queue.
It merges the lowest open Change Request first,
waits for that merge to settle,
syncs trunk,
restacks and updates the next branch,
waits for CI checks on the updated Change Request,
and repeats until the requested downstack has been merged.

The command is gated behind the downstackMerge experiment
while the merge-queue behavior is still settling.

Merge flow

For a stack like:

main <- feature1 <- feature2 <- feature3

running gs downstack merge from feature3 merges:

feature1, feature2, feature3

After each merge,
repo sync updates trunk,
deletes merged branches,
and retargets their upstacks.
The next queued branch is then restacked,
submitted as an update to its existing Change Request,
checked for passing CI,
and merged.

This keeps squash-merge handling in the merge queue itself,
rather than relying on delete cleanup to repair the stack afterward.

Test support

ShamHub now supports:

• shamhub config mergeMethod merge
• shamhub config mergeMethod squash

This lets script tests exercise server-side squash merge behavior
for gs downstack merge.

Refs #65

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

[abhinav]

@ed-irl I'm still working through this. Marked it as draft so I don't accidentally merge it.
I'm hoping to have this in this weekend.
One note:
I'm renaming this to downstack merge since that's the scope. That'll allow a "merge only this branch" branch merge command in the future as well as a stack merge that somehow handles upstack fan out.

Update: I've made a bunch of changes.
This became a forcing function for finishing up #1197, which bubbled into #1199, #1201.

[abhinav]

Thanks for the change, @ed-irl!
Minus the rename, I simplified some of the logic to take advantage of improvements to state handling in sync handler, delete handler, etc.
I've also marked this feature experimental/opt-in because I expect to make some changes to it in the near future.