The rule needed the other cause too

This MR's own first pipeline failed with the message it was written to explain,
for a cause it did not cover: the branch was cut before another regeneration
landed, so it carried the old pages while the source had moved on. Same guard,
same output, and the remedy is the opposite one — `git merge main`, not
`build-doc-pages.sh`, which produces no diff and leaves you stuck.

A rule that names one of two causes is worse than none, because it sends the
reader confidently down the wrong path. Both are written down now, with a
command that tells them apart.

CONTRIBUTING.md

@@ -84,6 +84,19 @@ new hash after the source is on e2e main, so between "source lands" and
 command that did not work; the guard exists because of that, and a green that
 means nothing is how it comes back.
 
+⚠️ **The same failure has a second cause, and the fix is the opposite one.** If
+your branch was cut before somebody else's regeneration landed, it carries the
+old pages while the source has moved — identical message, but running the
+generator produces no diff and leaves you stuck. Merge `main` in instead. Tell
+the two apart by asking whether `main` already has a newer page than your branch:
+
+```bash
+git fetch && git log --oneline HEAD..origin/main -- Resources/Views/
+```
+
+Anything listed there means it is staleness against `main`, not against the
+source.
+
 ⚠️ A slow queue makes this window long rather than momentary — the first time it
 happened, a two-minute gap became most of an hour. See the issues labelled `ops`.