Add MCP tools for GitHub Stacked PRs (gh stack link / sync / view)

まず既存の create_pull_request ツールと update_pull_request ツールを確認し、その後、それらの base の連鎖動作を、提案されている get_stack および link_stack 操作と比較します。エージェントがネイティブな stack を読み取り、順序付けられた pull request または branch のリストから stack を作成または更新でき、順序付けられた layer と trunk が返されれば、最小限の v1 は完成です。

Describe the feature or problem you’d like to solve

Agents that manage stacked / dependent PRs (each PR’s base is the branch below it) can already create and re-base-point individual PRs via create_pull_request / update_pull_request, but they have no first-class way to:

1. Discover or read a GitHub native stack (the stack object / annotations created by gh stack link / gh stack submit)
2. Create or update that stack as a unit
3. Cascade-rebase / sync the tower when trunk moves (gh stack sync / gh stack rebase)
4. Merge bottom-up with stack-aware ordering

Today the only path to native stacks is the gh stack CLI extension (github/gh-stack), which many agent environments intentionally don’t expose (token stays on a host proxy; container gh is stubbed; agents talk to GitHub through this MCP).

Proposed solution

Add a small stack toolset (or extend pull_requests) that mirrors the operations agents already need from gh stack, without shelling out:

Minimum useful v1: read + link (get_stack, link_stack). Agents can already do Path-B base-chaining with update_pull_request(base=…); what’s missing is the native stack object and a single call that wires N PRs correctly.

Example

link_stack(
  owner: "org",
  repo: "app",
  base: "develop",          # trunk
  pull_numbers: [7609, 7797, 7810, 7815, …]  # bottom → top
)
→ { stack_number: 7928, prs: [...] }

get_stack(owner, repo, stack_number: 7928)
→ ordered layers with number, head, base, mergeable, reviewDecision