docs(skill): cover --accept-base-change for non-interactive sync/rebase after a base retarget #619

v0.3.0 added base retargeting (#590): when a stack's base branch is deleted, GitHub moves the stack onto a new base, and sync/rebase rebase onto it. The CLI reference documents the non-interactive path in the "Retargeted stacks" paragraph under gh stack sync:

If the old base did not merge into the new base, they ask before dropping its commits; in a non-interactive terminal, pass --accept-base-change. Until the stack is rebased, push and submit stop, and view reports the new base.

The agent skill (skills/gh-stack/) doesn't mention retargeting or the flag, at v0.3.0 and still on main. Traced in the v0.3.0 source (not reproduced end to end), an agent running with stdout not a TTY hits this:

• push/submit exit 1 with run `gh stack sync` to rebase the stack onto <base> before publishing (requireCurrentBase).
• sync/rebase then exit 1 with stack not rebased; rerun with --accept-base-change to rebase onto <base> when the old base is not known to have merged into the new one (retargetCutoff, cmd/utils.go).
• Both use ErrSilent, so the skill's exit-code table only says "read stderr", although the skill tells agents to branch on exit codes rather than parse stderr.
• The flag is consent to drop the old base's commits from the stack. "Not known to have merged" includes cases where the merge check couldn't confirm it (e.g. the PR lookup failed), so the stderr hint alone isn't enough for an agent to decide.

Suggested change

Detail in references/troubleshooting.md, with a pointer from SKILL.md.

SKILL.md, end of "Staying in sync":

+If GitHub retargeted the stack (its base branch was deleted), `sync`/`rebase` can exit 1 with
+`rerun with --accept-base-change`, and `push`/`submit` stop too — see `references/troubleshooting.md`.

references/troubleshooting.md, new section next to "Local and remote stacks have diverged":

## Stack retargeted to a new base

When a stack's base branch is deleted, GitHub moves the stack onto a new base without rebasing it.
`sync` and `rebase` rebase onto the new base and drop the old base's commits from the stack. When
the old base is not known to have merged into the new one, non-interactive runs change nothing and
exit **1** with `stack not rebased; rerun with --accept-base-change`. `push` and `submit` also stop
until the stack is rebased.

Before passing the flag, check whether the old base's PR merged (the warning above the error names
the old base): `gh pr list --state all --head <old-base>`. If it merged into the new base, the
commits already landed and the flag is safe. If it did not, the flag removes those commits from the
stack — tell the user and wait for their go-ahead.

Possibly worth a CLI change too: a typed exit code for this refusal (alongside exits 2–10 in cmd/utils.go) would let the exit-code table cover it without stderr parsing. Happy to split that into its own issue.

(Separately, the frontmatter at v0.3.0 still says version: "0.2.0" — same drift as #499.)

Happy to open a PR with this patch if that's easier than applying it directly.