fix: publish/sync merge generated files mechanically and carry non-overlapping uncommitted work through a rebase (#180)

Overlap only in kb/index.md, kb/log.md, kb/provenance.md and kb/**/INDEX.md no longer
fails a reconcile or reaches the rebase-review gate: the log keeps both sides' entries,
the catalog and provenance are regenerated. Uncommitted work no incoming commit touches
rides through the rebase via --autostash; the working tree is backed up under
refs/wikitool/reconcile-backup first. is_generated is narrowed to kb/.

Files changed:
- CHANGES.md
- VERSION
- instructions/gates.md
- instructions/session-setup.md
- tools/CONTRACT.md
- tools/chemenu/commands/git_publish.py
- tools/chemenu/commands/index_build.py
- tools/chemenu/commands/provenance_cmd.py
- tools/chemenu/tests/test_git_publish.py

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

instructions/gates.md

@@ -36,7 +36,8 @@ Read the exit code first - it says which of these applies:
 A `wikitool` command that exits **42** is not reporting an error. It is refusing to act until a
 human has *read its output*. Five gates use it today - the Mass-Update Gate (`publish`, on a
 change touching 10 or more counted files), the rebase-review gate (`sync` and `publish`, on
-a rebase whose incoming commits touch a file this session is also changing), the
+a rebase whose incoming commits touch a file this session is also changing, generated files
+aside), the
 Publish-Remote Gate (`publish`, on a push to a target this checkout has not declared), the
 Upload Review Gate (`upload accept`, on a submission nobody has cleared yet), and the Guideline
 Push Gate (`export guidelines --push`, before a generated `GUIDELINES.md` goes into any captured
@@ -54,7 +55,9 @@ For the rebase-review gate the substance is different: the commits arriving from
 the files they touch that this session is also touching, and a diff of those files. Read it -
 this is the check `sync`/`publish` cannot perform themselves, since a rebase between two commit
 ranges that touch disjoint files never reaches this gate at all (no content collision is
-possible by construction, so it rebases automatically). Judge whether the incoming change
+possible by construction, so it rebases automatically). Nor does an overlap only in the files
+`wikitool` generates - the catalog, `kb/log.md`, `kb/provenance.md` - which carry no decision
+and are merged and regenerated mechanically; the gate never lists them. Judge whether the incoming change
 conflicts logically with what you are about to publish, summarize *that judgment*, not just the
 diff, to the user, and only then re-run with the `--confirm-rebase <token>` the refusal prints.
 

instructions/session-setup.md

@@ -85,7 +85,11 @@ than one machine or session writes to. Running `sync` first shrinks that window
 the session instead of discovering the drift only at the very end.
 
 `sync` fetches the remote and fast-forwards or rebases automatically when that is safe; it
-never commits and never pushes. **Exit 42 (rebase-review)?** Same as any exit 42 - read the
+never commits and never pushes. Files `wikitool` generates are never a reason to stop: when the
+catalog or `kb/log.md` changed on both sides, `sync` keeps both sides' log entries and
+regenerates the catalog and `kb/provenance.md`, which it leaves as an uncommitted change for the
+next `publish`. Uncommitted work that the incoming commits do not touch stays where it is.
+**Exit 42 (rebase-review)?** Same as any exit 42 - read the
 diff it prints, judge whether it conflicts with what you are about to do, summarize that to the
 user, then `tools/wikitool sync --confirm-rebase <token>` before continuing. See
 [gates.md](gates.md).