feat(config): lens sections - a repository's own text appended to a shipped charter

A lens has one charter, the one this pipeline ships; what a repository
knows that is not general to the lens - its platform and layers, the
record it keeps its decisions in, what its users already have, the
calibration entries that are its own - goes in a file the config names
for the lens (lenses.<name>.section), and Charter appends it after one
blank line. The charter sha in every reuse key covers the combined text.

The config refuses a path outside the repository - absolute, or
climbing out with `..` - by the check slots.dir had, now one both
settings share; a file missing or one the run could not use (a dangling
link, unreadable, not UTF-8) is a problem too, checked through the
reader Charter uses (Prompt::ReadSection), so a section is never
dropped in silence, and a name that is no lens is the unknown key it
always was. Nothing lists a directory, so what lies beside the files is
no concern of the config's: a directory listed would have to tolerate or
refuse every foreign entry. The run logs which charters got one.

The better-solution charter gains a consumer's general entry
(2026-10-31: a mechanism reworked a second time in one submission is the
signal to derive the fix at every layer the data crosses). The procedure
names the section wherever it names the charter: among the config's keys,
in the lens inputs, in the reuse rule (an edit to either re-runs the lens)
and in the feedback loop, which routes a repository's own lesson to its
section and a general one to the shipped charter.

process/lenses/repo-better-solution.md

@@ -98,3 +98,10 @@ record is a `reserve-answer` or `info` note. Never grade a finding.
   polished over six rounds and removed by the owner in one line ("they can
   be viewed in the releases tab"). Ask first whether the thing needs to exist
   in the tree at all.
+- 2026-10-31 (round 9 of a consumer's first push): rounds 6–8 reworked an
+  app's mapping of a daemon's message ids three times before round 9 asked
+  whether the ids should be unique at the layer that mints them — the
+  daemon's, a repository of the same owner, where the fix was one change. A
+  mechanism reworked a second time in one submission is the signal: at the
+  second rework, derive the fix at every layer the data crosses before
+  another variant on the consuming side.