docs(changelog): lead the /land entry with enqueue-and-forget + onboarding

Reframes the v1.56.0.0 entry around the fire-and-forget workflow (queue a stack,
walk away) and the first-time trunk.io handholding. No version bump — folds into
the open PR's existing entry.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -2,9 +2,11 @@
 
 ## [1.56.0.0] - 2026-05-31
 
-## **`/land` is a standalone skill now, and it speaks merge queues. Trunk.io, GitHub native, or none, driven the way each one actually expects.**
+## **`/land` is a standalone skill now, and on a merge queue it's fire-and-forget: enqueue a stack of green PRs, walk away, and the queue lands them all on the base branch.**
 
-There is now a `/land` skill that does exactly one thing: take a green PR and merge it through the right regime, with the full readiness gate (reviews, tests, docs, the one irreversible-merge confirmation) intact. `/land-and-deploy` no longer carries its own copy of that logic; it composes `/land` and then deploys. So the merge path lives in one place, and that one place understands three worlds: no queue (`gh pr merge --squash`), GitHub's native merge queue (`gh pr merge --auto`), and the trunk.io merge queue. Trunk works the moment its GitHub App is installed, with zero extra auth, because the default submit path is a `/trunk merge` PR comment. The trunk CLI and REST API are picked up automatically when present, for queue position and priority.
+There is now a `/land` skill that does exactly one thing: take a green PR and get it onto the base branch through the right regime, with the full readiness gate (reviews, tests, docs, the one irreversible-merge confirmation) intact. The headline behavior on a merge queue is what you actually want when a pile of PRs is ready: `/land` enqueues the PR and returns. It does not sit and babysit. You run `/land` on each ready PR and walk away, and the queue tests them in parallel and lands them on the base branch for you, optimistically (a later PR that already contains an earlier change can rescue it from a flaky failure). No more merge-one, wait, merge-the-next. When you do want to watch a single PR land, `/land --watch` blocks; `/land-and-deploy` always watches, because it needs the completed merge before it can deploy.
+
+`/land-and-deploy` no longer carries its own copy of the merge logic; it composes `/land` and then deploys. So the merge path lives in one place, and that one place understands three worlds: no queue (`gh pr merge --squash`), GitHub's native merge queue (`gh pr merge --auto`), and the trunk.io merge queue. Trunk works the moment its GitHub App is installed, with zero extra auth, because the default submit path is a `/trunk merge` PR comment. The trunk CLI and REST API are picked up automatically when present, for queue position and priority. Never set up a merge queue before? `/land` explains what a merge queue is in plain English before it does anything, and walks you through trunk.io setup step by step the first time.
 
 The trick that keeps this cheap: the submit command differs by regime, but the "did it land" signal is identical. All three end with the PR in `MERGED` state and a commit on the base branch, so one uniform poll (plus the `Trunk Merge Queue (<branch>)` status check for ejection) covers every regime. Detection reads that same status check, not the `.trunk/` directory (which the trunk linter also uses), so a repo that runs `trunk check` but not the queue is correctly read as "no queue."
 
@@ -24,12 +26,14 @@ The merge SHA the deploy half needs for a revert now travels as an explicit, val
 
 ### What this means for you
 
-If you only want to merge, run `/land` and stop. If you want merge plus deploy plus canary, run `/land-and-deploy` exactly like before; it just routes the merge through `/land` now. On a trunk.io repo, gstack stops fighting the queue and uses it: it enqueues, watches the queue's own status check, and tells you plainly if the queue ejects the PR. Set the regime once in CLAUDE.md (`/setup-deploy` writes it) or let `/land` detect it. Non-trunk users pay nothing for any of this.
+If you only want to merge, run `/land` and stop. Got ten PRs green and ready? Run `/land` on each and walk away; the queue lands them all without you sequencing merges by hand. If you want merge plus deploy plus canary, run `/land-and-deploy` exactly like before; it just routes the merge through `/land` now (in watch mode, since it deploys the result). On a trunk.io repo, gstack stops fighting the queue and uses it: it enqueues, points you at the queue's own status check and dashboard, and tells you plainly if the queue ejects the PR. Set the regime once in CLAUDE.md (`/setup-deploy` writes it) or let `/land` detect it and offer to set trunk.io up for you. Non-trunk users pay nothing for any of this.
 
 ### Itemized changes
 
 #### Added
 - **`/land` skill**: lands a PR standalone: pre-flight, CI wait, VERSION-drift check, the pre-merge readiness gate (with a `--fast` flag that skips soft-warning prompts but never a real blocker), and a regime-aware merge. Writes a `last-land.json` handoff and prints a `LANDED:` line on success.
+- **Enqueue-and-return is the default on a merge queue.** `/land` hands the PR to the queue and returns, so you can `/land` a stack of ready PRs and walk away while the queue lands them in parallel. `--watch` opts into blocking until a single PR lands (and is what `/land-and-deploy` uses). A no-queue repo merges synchronously, as before.
+- **First-time merge-queue onboarding.** When a repo has no queue configured, `/land` offers to set trunk.io up and hand-holds the whole thing: install the GitHub App, create the queue, the three branch-protection changes, and the optimizations (optimistic merge, parallel, batching) that make "queue many, walk away" work. It also explains, in plain English, what a merge queue is before doing anything. The walkthrough lives in one shared place, used by both `/land` and `/setup-deploy`.
 - **Merge-queue support for three regimes**: none, GitHub native merge queue, and trunk.io. Trunk submit is comment-first (`gh pr comment "/trunk merge"`, zero new auth), with the trunk CLI and REST API (`$TRUNK_API_TOKEN`) as automatic upgrades for priority and queue position.
 - **`bin/gstack-merge`**: a small, unit-tested helper (`detect` / `submit` / `wait` / `write-state` / `read-state`) backed by `lib/merge.ts`. The same `detect` powers `/land`, `/land-and-deploy`'s dry-run, and `/setup-deploy`, so they never disagree.
 - **`## Merge Configuration` in CLAUDE.md**: `/setup-deploy` now records `Merge queue: none|github|trunk` separately from deploy settings, so `/land` reads merge config with zero deploy coupling.