AGENTS.md § Gates is the one gate list; cli_contract.GATES and docs verify hold it

The gate list contradicted itself across AGENTS.md, instructions/gates.md and the
command records' gate names. The Rebase-Review Gate is now listed, `new project`'s
exit 42 is no longer a pseudo-gate, gates.md and the explanation page link to the one
list instead of counting, and a register plus a docs verify check keep the three in step.

Files changed:
- AGENTS.md
- CHANGES.md
- VERSION
- docs/explanation/why-gates-are-code.md
- docs/reference/commands/pages.md
- docs/reference/commands/types-instructions-and-docs.md
- docs/reference/exit-codes.md
- instructions/gates.md
- tools/CONTRACT.md
- tools/chemenu/cli_contract.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/git_publish.py
- tools/chemenu/commands/new_page.py
- tools/chemenu/errors.py
- tools/chemenu/mcp/server.py
- tools/chemenu/tests/test_cli_contract.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_git_publish.py
- tools/chemenu/tests/test_reference_doc.py

Co-Authored-By: Claude Code <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

docs/explanation/why-gates-are-code.md

@@ -1,10 +1,8 @@
 # Why gates are code
 
-Chemenu has five hard limits - the Mass-Update Gate, the Publish-Remote Gate, the Upload Review
-Gate, the Guideline Push Gate, and the Iteration Budget Gate - and all five live inside
-`tools/wikitool`, not in a
-paragraph of instructions an agent reads and follows. The rules themselves, and what to do when
-one trips, are in [AGENTS.md § Gates](../../AGENTS.md#gates) and
+Chemenu's hard limits - the gates [AGENTS.md § Gates](../../AGENTS.md#gates) lists - live inside
+`tools/wikitool`, not in a paragraph of instructions an agent reads and follows. The rules
+themselves, and what to do when one trips, are in [AGENTS.md § Gates](../../AGENTS.md#gates) and
 [instructions/gates.md](../../instructions/gates.md). This page is only about the design choice
 underneath them: why code, and why these mechanisms in particular.
 
@@ -34,8 +32,8 @@ well-written instruction - it's that code doesn't get talked into anything.
 
 ## Why different mechanisms, not one
 
-The five gates ask four different kinds of question, and each one's shape follows from what kind
-of question it is.
+The gates ask different kinds of question, and each one's shape follows from what kind of
+question it is.
 
 The Mass-Update Gate asks *is this change too large to publish unreviewed* - a judgment that
 varies changeset by changeset, so it clears with a `--confirm` token tied to the specific
@@ -51,7 +49,7 @@ editing `.wikitool-remotes.json` directly, outside the gate's own flow.
 The Upload Review Gate asks the Mass-Update Gate's own question - *is this change right?* - at
 the opposite end of its size range: one file from a stranger instead of a changeset from the
 session's own work. That similarity is exactly why it reuses the same shape (a `--confirm` token
-digesting the thing being approved) rather than inventing a fourth one: the two gates differ in
+digesting the thing being approved) rather than inventing a new one: the two differ in
 *who* produced the change and *how much* of it there is, not in what kind of question either one
 is answering, so nothing about the mechanism needed to change - only the boundary it sits behind
 did, since the submission lives in a quarantine the ordinary pipeline never reads at all rather
@@ -68,14 +66,24 @@ standing, committed declaration - the capture manifests under `raw/` - and askin
 URLs in an allowlist as well would be a second declaration of one fact. What is left to ask is
 the per-run question, and that is the one a token answers.
 
-The Iteration Budget Gate asks a fourth kind of question - not "is this instance correct" but
+The Rebase-Review Gate asks the one question the others cannot: *does what is arriving collide
+logically with what I am about to publish?* `sync` and `publish` reconcile with the remote by
+rebasing, and when the incoming commits touch a file this session is also changing, git can
+produce a clean textual result out of two changes that contradict each other. Whether they do is
+a question of meaning, not of text, so the tool cannot answer it - it can only refuse, and show
+the incoming commits, the overlapping files and their diff to whoever can. The answer is different
+for every rebase, which is why it takes the token shape: the token digests the exact upstream
+state and the overlapping files, so a remote that moved again before the re-run is a new
+question, asked again.
+
+The Iteration Budget Gate asks a different kind of question - not "is this instance correct" but
 "has this session stopped making progress." That's read from the shape of the call history
 itself (call count, repeated identical calls), not from anything about the content of any one
 call.
 
 ## Exit 42 is a posture, and it outgrew the gates
 
-Those five are the named gates, and they are not the only thing that exits 42 any more. When the
+Those are the named gates, and they are not the only thing that exits 42 any more. When the
 task-tracker provider layer arrived, it brought a case that looks like a gate from the outside and
 is not one: a provider whose API cannot create a project (Super Productivity's local REST API
 reads projects but does not write them) raises `HumanInterventionRequired`, and the command prints