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

## 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:

| Tool | Purpose |
|---|---|
| `list_stacks` / `get_stack` | Resolve a stack by number, PR number, or head branch; return ordered PRs + trunk |
| `link_stack` | Create/update a stack from an ordered list of PR numbers or branches (`gh stack link`) |
| `update_stack` | Reorder / reparent / drop layers |
| `sync_stack` | Cascade-rebase onto trunk + push with lease semantics (`gh stack sync`) — or return structured rebase instructions if server-side git is out of scope |
| `merge_stack` | Merge bottom-up, stopping on the first non-mergeable layer |

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

```text
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

Start by reviewing the existing create_pull_request and update_pull_request tools, then compare their base-chaining behavior with the proposed get_stack and link_stack operations. A minimum v1 is complete when agents can read a native stack and create or update one from an ordered list of pull requests or branches, with ordered layers and trunk returned.

Rédigé par le modèle d'indexation à partir du texte de l'issue.