feat: a subtype gets its own page skeleton from types/<type>.<value>.md (#117)

Files changed:
- AGENTS.md
- CHANGES.md
- README.md
- VERSION
- docs/ownership-and-templates.md
- instructions/evolve-subtypes.md
- instructions/setup-instance.md
- instructions/subtype-templates.md
- instructions/upgrade-instance.md
- tools/CONTRACT.md
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/new_page.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_new_page.py
- tools/chemenu/tests/test_toc.py
- tools/chemenu/tests/test_type_resolver.py
- tools/chemenu/toc.py
- tools/chemenu/type_resolver.py
- types/concept.decision.md
- types/entity.guidance.md
- types/entity.md
- types/entity.person.md
- types/type-spec.md

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

docs/ownership-and-templates.md

@@ -127,8 +127,8 @@ stack-owned file (`types/<name>.guidance.md`) holding exactly the half that used
 when to use the type, when not to, and mechanism-level advice that holds for every instance. That
 file ships verbatim and upgrades like any other machinery file, whether or not the type-spec that
 links it has ever been adopted. `types/type-spec.md` §§ "Who owns a type-spec" and "Anatomy of a
-type" hold the current shape; `tools/wikitool types describe <name>` composes both files into one
-answer, so an agent asking for a type's contract never needs to know it comes from more than one
+type" hold the current shape; `tools/wikitool types describe <name>` composes the type-spec and its
+guidance into one answer, so an agent asking for a type's contract never needs to know it comes from more than one
 file. An instance that adopted its type-specs before this split existed takes it as an *offered*
 migration rather than something an upgrade applies on its own - the same reasoning as any other
 instance-owned file in the middle category below, spelled out for this one case because it is the
@@ -149,8 +149,12 @@ becomes visible once an upgrade is a command rather than a hand-run copy:
   kb` type-spec's optional `types/<name>.guidance.md` sits: verbatim, even though the type-spec
   it documents (below) is not.
 - **`.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
+  `kb/<name>/COLLECTION.md`, `ENVIRONMENT.md`, the `root: kb` type-specs and their subtype
+  templates `types/<name>.<value>.md` - are never written by an upgrade at all. A subtype
+  template is the guidance split run the other way: the file boundary cut once more, this time
+  to give page material a file of its own, and page material belongs to the instance, so it
+  lands here rather than among the verbatim files - and because it is its own file, a release
+  can ship a new one without touching an adopted type-spec. 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. The same
   property has a second face on the way in: when a release ships a `.template` for a type or
   collection the instance does not have *yet*, the upgrade writes the template and stops - it