docs: dist upgrade - Stamp-Semantik nach --keep-local, drei Eigentumsklassen in docs/ (#7)

Files changed:
- CHANGES.md
- VERSION
- docs/ownership-and-templates.md
- tools/CONTRACT.md

docs/ownership-and-templates.md

@@ -4,7 +4,8 @@ Chemenu ships two kinds of files side by side, and at a glance they look the sam
 plain markdown, both sit in the repo root or under `kb/`, both get read at session start. But a
 stack upgrade treats them completely differently. Some - [AGENTS.md](../AGENTS.md),
 [kb/CONTRACT.md](../kb/CONTRACT.md), the per-stage contracts - are identical in every instance
-that runs this stack and can simply be overwritten by the next release. Others - `USER.md`,
+that runs this stack and are the next release's to replace (with one caveat about local edits,
+below). Others - `USER.md`,
 `SOUL.md`, `kb/CONVENTIONS.md`, `ENVIRONMENT.md` - describe one particular instance, and
 overwriting them would silently erase a choice someone made on purpose.
 
@@ -82,9 +83,33 @@ state rather than a sign setup was skipped.
 
 ## The consequence in practice
 
-Running a stack upgrade against an existing instance boils down to: overwrite the verbatim
-files, leave the `.template`-sourced files alone. The verbatim files are safe to replace
-wholesale because they were never instance-specific to begin with - identical content going
-back in changes nothing an instance actually decided. The template-sourced files were filled in
-once, by a person, for a reason, and nothing about a newer release of the stack's mechanics
-gives it standing to override that.
+An upgrade sorts every shipped path into three categories, not two - and the third one only
+becomes visible once an upgrade is a command rather than a hand-run copy:
+
+- **Verbatim files** - `AGENTS.md`, `kb/CONTRACT.md`, the per-stage contracts, everything under
+  `tools/`, `types/` and `instructions/` - are the release's to replace.
+- **`.template`-sourced files** - `USER.md`, `SOUL.md`, `kb/CONVENTIONS.md`, each
+  `kb/<name>/COLLECTION.md`, `ENVIRONMENT.md`, the `root: kb` type-specs - are never written by
+  an upgrade at all. The distribution ships only the `.template` beside them, so the filled file
+  is out of reach by construction rather than by a rule someone has to remember.
+- **Seeded-once files** - `.wikitool-kb.json`, `CHANGES.md`, `kb/log.md`, `raw/*/.gitkeep` - are
+  written into a *new* instance by `dist export` and belong to the instance from then on. They
+  are the awkward category: they sit in the release stamp's file list like any other shipped
+  file, so an upgrade has to exclude them deliberately (`chemenu.ownership.is_export_stub` and
+  `is_upgrade_preserved`). An upgrade that re-seeded them would reset the record of which
+  migrations ran, or erase the changelog the instance wrote for itself.
+
+The first category carries a caveat that the word "verbatim" hides. It says who *decides* the
+content, not that overwriting is always safe: an instance can still have edited a verbatim file
+- a patched `tools/`, a locally adjusted instruction - and an upgrade assuming otherwise would
+destroy that silently. Avoiding that assumption is the whole reason `dist export` records a
+sha256 per shipped file in `.wikitool-release.json`. `wikitool dist upgrade` compares every
+candidate path against the digest recorded when it was installed, overwrites only what still
+matches, and refuses rather than overwrite what does not.
+
+So the practical rule is narrower than "overwrite the verbatim files, leave the rest alone":
+overwrite the verbatim files *this instance has not touched*, never write the other two
+categories, and make a locally changed file a decision someone takes deliberately instead of
+one an upgrade takes for them. The template-sourced files were filled in once, by a person, for
+a reason, and nothing about a newer release of the stack's mechanics gives it standing to
+override that.