feat: add 'gs ci merge-guard' to block out-of-order stacked PR merges

[ed-irl]

Adds a gs ci merge-guard <number> command for forge CI/CD pipelines that fails when a change request's base branch is not trunk, preventing out-of-order merges in a stacked PR workflow.

merge-guard command

gs ci merge-guard <number> resolves the change, detects its trunk, and exits non-zero if the base branch is not trunk. Trunk is detected from the git-spice navigation comment on the PR, or overridden with --trunk. Unmanaged PRs (no navigation comment) are allowed through by default; --all blocks any PR whose base is not trunk. The new ci command group is registered under a CI group in the CLI.

Trunk metadata in navigation comments

To support detection, the navigation comment now embeds the trunk branch name via a trunk marker (<!-- gs:trunk main -->, or the Markdown link form for forges that use it). generateStackNavigationComment and updateNavigationComments take the trunk name, threaded through from h.Store.Trunk() in the submit handler. ExtractTrunkFromComment parses either marker form back out, and the previously unexported _navCommentRegexes is exported as NavCommentRegexes so merge-guard can reuse it to find navigation comments.

Tests

Unit tests cover ExtractTrunkFromComment (HTML, Markdown, missing, and full-comment round-trip) and the updated nav-comment generation. Script tests cover merge-guard for safe, blocked, deep-stack, --trunk override, unmanaged/--all, already-merged, closed, and not-found cases. Existing nav-comment golden files are updated to include the trunk marker.

[ed-irl]

This change is part of the following stack:

• restack: Add Options parameter to high-level restack entry points #1307
  • feat: add 'gs ci merge-guard' to block out-of-order stacked PR merges #1153 ◀

_{Change managed by git-spice.}

[abhinav]

@ed-irl is this intended as a guard in the merge command?
I don't think we need something like that?
merge only merges things that have trunk as base.
The original implementation had a bug where it would only guard the first branch in the stack.
Merged version fixes that.

[ed-irl]

@abhinav no, this is meant to be run in a Github action. This prevents people from hitting the "merge" button in github (or advises against it via a failed check anyways) if the target branch isn't the repo main branch.

[abhinav]

Okay, I can see the argument for guarding against human error with an optional CI integration.