docs(agents): --cherry-mark, not --cherry-pick, to find a back-port

Per @kriszyp, and verified empirically: --cherry-pick omits patch-equivalent
commits from both sides, so a back-ported commit is precisely what vanishes from
the output. I recommended it for finding back-ports, which is the opposite of
what it does.

On harper: `--cherry-pick --left-right v5.2.5...main` lists 79 commits with no way
to spot an equivalence, while `--cherry-mark` marks 6 with `=` — including real
v5.2 back-ports.

Now recommends --cherry-mark with the `=` marker, notes `git cherry` as the
shorthand, and warns against --cherry-pick explicitly, since the flag name reads
like it does the thing it actually suppresses.

Author: dawsontoth

AGENTS.md

@@ -57,7 +57,7 @@ Prefer plain ASCII characters in Markdown unless a typographic character is genu
 - **Determine that release from the core repo's git tags, not from the feature branch's `package.json`.** A branch reading `5.2.0-beta.3` says which release was open when the branch started, not which one the change lands in — if a release is cut before the feature merges, the badge is silently wrong. Check `git tag --sort=-creatordate` for the newest release, and `git tag --contains <merge-commit>` for whether the change is in one; a merged-but-untagged feature ships in the _next_ version, which may be a minor bump. Re-check on every refresh pass of a long-lived docs PR, because a release cut between passes invalidates a badge that was correct when written.
 - **Fetch tags and confirm the tag object before trusting the answer.** `git tag --contains` is only as good as the local tag it compares against: a stale or divergent tag of the same name gives a confidently wrong answer in either direction. Run `git fetch --tags`, then check `git rev-parse <tag>` against `git ls-remote --tags origin <tag>`. When a badge is disputed, the decisive check is not `--contains` at all but whether the feature's files exist at the tag — `git ls-tree -r --name-only <tag> | grep <path>`, or `git show <tag>:<file>` — since that cannot be confounded by ancestry or by which tag your clone happens to hold.
 - **A patch release may or may not be cut from `main`, so ancestry is not a reliable test.** Roughly a third come off `main` and the rest off a release branch such as `v5.2`, which carries selective cherry-picks. When a tag is cut from a release branch, `git tag --contains <main-merge-sha>` returns nothing for it _by design_ — `v5.2.5`'s commit is not an ancestor of `main` at all. So an empty `--contains` does not mean "unreleased", and a newer patch tag existing is not evidence against a next-minor badge. It tells you nothing either way until you know which kind of cut that tag was.
-- **Cherry-picks defeat ancestry checks entirely, so test for the feature's files instead.** A back-port creates a new commit SHA, so `git branch -r --contains <original-sha>` and `git tag --contains` both stay empty even when the feature is present on the release branch — which would wrongly badge a back-ported feature as next-minor. Ask whether the code is there, not whether the commit is: `git show <tag>:<path/to/feature/file>` or `git ls-tree -r --name-only <tag> | grep <path>`. `git log --cherry-pick --left-right <tag>...main` finds patch-equivalent commits when you need the commit rather than the file.
+- **Cherry-picks defeat ancestry checks entirely, so test for the feature's files instead.** A back-port creates a new commit SHA, so `git branch -r --contains <original-sha>` and `git tag --contains` both stay empty even when the feature is present on the release branch — which would wrongly badge a back-ported feature as next-minor. Ask whether the code is there, not whether the commit is: `git show <tag>:<path/to/feature/file>` or `git ls-tree -r --name-only <tag> | grep <path>`. When you need the commit rather than the file, `git log --oneline --cherry-mark --left-right <tag>...main` marks patch-equivalent commits with `=`; `git cherry <tag> main` is the equivalent shorthand. Do **not** use `--cherry-pick` for this — it _omits_ equivalent commits from both sides, so a back-port is exactly what disappears from the output.
 - **Compare commits, not tag objects.** An annotated tag's own SHA differs from the commit it points at, so two people can cite `v5.2.5` as different hashes and both be right. Use `<tag>^{commit}`.
 - Each minor release gets a file under `release-notes/<major-codename>/` (e.g. `release-notes/v5-lincoln/5.1.md`); the sidebar picks it up automatically.
 - Absolute links from `release-notes/` (or `learn/`) into current reference docs use the versioned path `/reference/v5/...` — the reference plugin maps the current version to the `v5` URL path.