docs(review): a diff never shows the prose it just falsified

[lilyshen0722]

Adds rule 15 to docs/development/review-checklist.md. Docs-only, additive; rule 14 verified byte-identical.

What earned it

Three instances today, all in careful PRs, all by the author who knew the subject best:

	the change	the sentence it falsified
#1001	removed the 30-minute pending delete	models/OnboardingSilenceEpisode.ts:18–19 — "AgentEvent pending rows are deleted at AGENT_EVENT_STALE_PENDING_MINUTES (default 30)", cited as the reason its event snapshot is NOT OPTIONAL
#1002	collapsed a double log emission	the comment it added in the same diff — "each failure already prints twice", as the reason to stamp both sinks; its own new test now forbids that behaviour
#997	—	the AX entry drafted the same hour, cataloguing this identical defect on two product surfaces

The third is the tell, and it is why this is worth a rule rather than two review comments: a room that could name the failure in the product could not see it in its own diffs.

Why it is a reviewer's rule

The author is structurally the last person who will notice, because they hold the pre-change model in their head as the thing being fixed. In #1002 that is sharper than distance — the stale sentence is inside the diff, five lines from the change, freshly written, still describing the before-state, because it was drafted while the bug was live.

Hence this file rather than REVIEW.md, per the split that file already states: authors pre-PR there, reviewers mid-PR here.

The check

Mechanical and cheap. For each behaviour the PR alters, git grep the constant, env var, status value, threshold or tool name it touches, and read every prose hit — comments never appear in a diff of the code they describe.

Two riders are included because each changes what the fix should be:

1. The stale sentence is usually load-bearing — the stated justification for a design decision ("WHY X IS NOT OPTIONAL"), so the next reader inherits a false model of the system, not a cosmetic inaccuracy.
2. Its conclusion is often still correct for a different surviving reason. Both instances above are like this: both sinks do still need stamps, the snapshot may still be worth keeping. So rewrite the reason rather than deleting the rule — and say which, or the next reader removes a constraint that still holds.

Ran the rule on this diff

Since it would be a poor rule to break while adding it: git grep review-checklist turns up CLAUDE.md:173, REVIEW.md:20, REVIEW.md:242, docs/development/README.md:16 and ADR-019. All describe the file by nature ("incident-derived rules, each naming the defect that earned it") rather than by length or contents, and ADR-019's citation of rule 9 by number is unaffected by an append. Nothing goes stale.