Remaining AI feature surface: stacked PRs, AI gates, post-merge actions, issue quick-links

The last of the AI feature surface, after #1393 wired the triggers. Each is additive against shapes that already exist and are tested.

Stacked PRs for finishing touches (#1380)

• Provider: branch off a PR's head branch, open a PR targeting that branch
• Verification gate: run the repo's tests in the sandbox, commit on green, degrade to committable suggestions on red
• Consume parseTouchSelections from the review comment's checkboxes (same machinery as the dashboard boxes)

AI pre-merge checks (#1382)

• Linked-issue assessment: does the diff actually address the linked issue?
• Custom natural-language assertions from gates.preMerge.custom
• Both return the existing GateResult shape, so summarizeGates needs no change
• Skip with a neutral conclusion when no AI key is configured

Post-merge actions (#1382)

• pull_request: [closed] trigger filtered to merged == true
• Built-ins: changelog append, comment on linked issues, dashboard refresh
• Custom prompts running in a read-only agent tier with one write target

Issue quick-links (#1383)

• issues: [opened] trigger
• Quick-links comment offering "Make a plan" / "Build this" as checkboxes
• Wire renderPackageContext to the scanner's dependency list so the dependency-context comment posts automatically

Docs

• docs/ai/review.md, docs/ai/commands.md, docs/gates.md — the features shipped ahead of their documentation

Landed in dec1a7a.

AI pre-merge checks: linked-issue assessment and custom natural-language assertions, both returning the existing GateResult shape so summarizeGates needed no change. Every one degrades to a neutral result — not a pass — when no provider is configured, when the provider errors, or when the verdict is malformed. A check that could not run must never read as one that succeeded. Assertions are one request each so an unanswerable one cannot sink the rest. Diff and issue body are delimited as untrusted content with the verdict constrained to a boolean and a reason.

Post-merge actions: changelog append, comment on linked issues, dashboard refresh — each independently failure-tolerant, since the PR has already merged. The changelog appender never touches a released section and never doubles an entry on a re-run. isMergeEvent guards the path, since pull_request: [closed] fires for abandoned PRs too.

Issue quick-links: both actions are unticked checkboxes. The marker carries an action id rather than a label, so retitling a button later cannot change what an already-posted comment triggers, and an unknown id never reaches the dispatcher.

New CLI: buddy-bot gate <pr> and buddy-bot post-merge <pr>.

Stacked PRs for finishing touches were not implemented — opening a follow-up.

The deferred item — stacked PRs for finishing touches — landed in a66a329.

The delivery mechanism resolves the safety question I flagged when deferring it: Buddy Bot never commits to the contributor's branch, it opens a PR targeting that branch. Merging it adds the change to their pull request, and they review it first. A test asserts the contributor's branch is byte-identical after a touch runs.

Changed files come from git status, not the agent's self-report — an agent that reports a file it did not touch would otherwise decide what gets committed. Deletions are excluded.

Three things degrade to committable suggestions rather than a branch: failing tests, a suggestion-only touch like plan, and an agent that stopped before finishing. That last one matters — an agent that hit a limit mid-edit left the tree in a state it did not choose, and publishing it as a branch would present an interrupted change as a considered one.

A repository with no test script reports ran: false, not passed: false, and the resulting PR says plainly that it is unverified. Only a declared test script is run: guessing bun test at a project without one runs zero tests and reports success, which would let an unverified change through as verified.

New CLI: buddy-bot touch <pr>.