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.

Written by the indexing model from the issue text.