feat(github): add optional GitHub Stacks integration for native stack UI

[mrmans0n]

Summary

Add optional GitHub Stacks integration so git-gud can register/update stacked PR chains in GitHub when the repository has GitHub Stacks enabled.

Motivation

git-gud already creates GitHub PR stacks in a way that appears structurally compatible with GitHub's new Stacked PRs UI:

• one branch per stack entry
• the first PR targets the base branch
• each subsequent PR targets the previous entry branch
• gg sync already updates PR base branches when needed

This means the hard part is already solved. The missing piece is a best-effort integration layer that tells GitHub "these PRs form a stack" so repositories with the feature enabled can benefit from the native stack UI.

Current state

Today git-gud already does all of this:

• creates per-entry branches for each stack layer
• creates GitHub PRs with the correct base chain
• updates existing PR base branches with gh pr edit --base
• tracks entry-to-PR mappings locally
• preserves stable internal metadata with GG-ID / GG-Parent

That should be enough for compatibility at the PR graph level.

Proposal

Add an optional GitHub-only integration that runs after gg sync finishes creating/updating PRs.

Config

Introduce a GitHub-specific config option:

{
  "defaults": {
    "github": {
      "stacks_integration": "auto"
    }
  }
}

Supported values:

• off: never attempt GitHub Stacks integration
• auto: attempt integration only when support is available
• force: always attempt integration and surface failures more explicitly

Default: auto

Sync behavior

At the end of gg sync, when provider = GitHub:

1. collect all active/open PR numbers in stack order (bottom → top)
2. if there are fewer than 2 active PRs, do nothing
3. detect whether GitHub Stacks support is available for the current repo
4. if available, create or update the remote GitHub Stack
5. if unavailable in auto, skip silently or with a minimal note
6. if integration fails, show a warning but do not fail gg sync

Implementation shape

Add a small abstraction in gg-core, for example:

• github_stacks.rs
• a GitHubStacksBackend trait or similar wrapper

This should allow us to support two backends:

Preferred backend: gh stack

If the official gh stack extension/command provides a safe way to adopt existing PR chains or register stacks for already-created PRs, prefer using it. This keeps git-gud aligned with GitHub's supported surface.

Fallback backend: direct GitHub Stacks API

If gh stack is not sufficient for adoption, add an experimental API backend that talks directly to the GitHub Stacks preview endpoints.

The backend choice should be hidden behind one integration layer so we can switch strategies later without touching the sync workflow.

Design constraints

• Keep git-gud's current stack model unchanged
• Do not remove or weaken GG-ID / GG-Parent
• Do not require GitHub Stacks for normal GitHub usage
• Do not affect GitLab behavior
• Treat the integration as best-effort and non-fatal

Why this is a good fit for git-gud

git-gud already has the exact data needed to build a remote stack:

• ordered stack entries
• entry branch names
• PR numbers for each entry
• open/merged state

So this should be a focused feature rather than a redesign.

Suggested tasks

• Add config support for defaults.github.stacks_integration
• Add GitHub Stacks availability detection
• Extract active PR numbers in stack order after gg sync
• Add best-effort remote stack sync step for GitHub
• Add tests for off, auto, force
• Add tests for partial stacks (merged lower entries, open upper entries)
• Document the feature in README, docs, and skills/gg

[ryanolson-dandy]

When this lands, my org might get into the pilot of github stacks. I'll try it out with git-gud. 🙌