Add native GitHub Stacks support (--github-stacks)

[ezyang]

GitHub Stacks (https://github.github.com/gh-stack/, private preview) is a
first-class REST resource: POST /repos/{o}/{r}/stacks with a bottom-to-top
list of PR numbers links them into a stack, /stacks/{n}/add appends, and
/stacks/{n}/unstack dissolves. The server requires each PR's base ref to
be the head ref of the PR below it, which is exactly what --direct submits
produce (and classic base-branch layout never satisfies), so the feature
requires --direct and warns otherwise.

Enable with ghstack --direct --github-stacks or persistently via
ghstack config github_stacks true.

After push_updates finishes updating PRs, _sync_github_stack reconciles
the server-side stack with the full local chain (all_diffs, not just the
submitted prefix, so prefix-only submits don't truncate an existing
stack): in-sync stacks are a no-op, new PRs on top are appended via /add,
and any other restructure is unstack + recreate since the API has no
reorder endpoint. All stack operations are non-fatal: a 404 (Stacks not
enabled) or any other error logs a warning and the PRs remain submitted
normally.

Live testing against pytorch/pytorch surfaced an undocumented rule that
shaped the design: once a PR is in a native stack, any PATCH /pulls/{n}
that includes the base field is rejected with 422, even if the value is
unchanged. Direct mode previously sent base on every update, so
resubmitting an unchanged stack would crash. Fixes: no-op base updates
are no longer sent at all, and when a resubmit genuinely retargets a PR
(e.g. inserting a commit mid-stack) the affected stack is dissolved first
(_unstack_prs) and recreated after. An alternative was to route
retargeting through a new stack-aware endpoint, but no such endpoint
exists in the API surface gh-stack v0.0.8 uses.

github_real.arest now returns None on 204 No Content (unstack returns
it). The fake endpoint models the stacks resource, including the
base-chaining rule on create/add and the no-base-PATCH rule, so the tests
exercise the same server behavior observed live.

Test Plan:

New test covers create, idempotent resubmit, append-on-top, and
mid-stack insert (dissolve + recreate) in both direct and non-direct
modes; full suite and linters pass:

uv run pytest test/submit/github_stacks.py.test -q
uv run pytest test test_cli_config.py -q
uv run python -m black --check src/ghstack/
uv run python -m flake8 src/ghstack/
uv run python -m mypy src/ghstack/

Verified live against pytorch/pytorch (which has Stacks enabled) with
draft [skip ci] PRs since the fake endpoint can only mirror observed
behavior: initial submit created stack #190147 (#190145 <- #190146),
unchanged resubmit was a no-op, a third commit was appended via /add,
and a mid-stack insert dissolved and recreated the stack as #190150 with
correct order. All test PRs, branches, and stacks were cleaned up.

This PR was authored with an AI assistant.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

[ezyang]

Stack from ghstack (oldest at bottom):

• -> Add native GitHub Stacks support (--github-stacks) #363