feat(propose): --shell-parent points a heading-only section at the ancestor holding its text

A plan entry whose span holds its heading alone gets `parent_id` naming the
nearest preceding entry at a smaller level whose own span holds text, passing
over an ancestor that is empty too; the door writes the existing `parent:`
key. Nothing is copied and no boundary moves. The rule reads the plan's level
and order, never the row. Off by default: `okf consume` reads no `parent`
key, so no payload ranks differently, while the flag moves the bytes of every
bundle holding a heading-only section.

Measured before building on one 2 761-concept process code: 710 concepts are
heading-only; the level route names the ancestor the document's own <sec>
nesting names on 708 of 710 (two sit at depth 7, clipped to 6, and point one
level too high), where reading section numbers gets 686 (`12` begins with
`1`); 35 have no ancestor holding text and get none.

The red test expected only concept files to move. The index is a projection
of the frontmatter and shows the key as a facet, so the test now holds both;
the facet renders a segment id as unresolved (`p1?`), because `structure`
reads `parent` as a document number -- named in README, CLAUDE.md and the
CHANGELOG, not repaired here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -153,6 +153,21 @@ whole. It adds any key and replaces only `sources` and `description`, the two
 with a layer below them (what the document declares, else the file name);
 every other key the door writes itself is refused before anything is read.
 
+`--shell-parent` (**off**; opt out explicitly with `--no-shell-parent`) gives a
+concept whose body is its heading alone a `parent:` naming the `segment_id` of
+the nearest ancestor that holds text — the nearest preceding plan entry at a
+smaller level, passing over an ancestor that is empty too. It copies no text
+and moves no boundary. It exists for a document that states its points once and
+lets every nested section inherit them: measured on one process code, **710 of
+2 761** concepts are heading-only, and the plan's level and order name the same
+ancestor as the document's own nesting on **708 of 710** (the two others sit at
+depth 7, which a markdown heading clips to 6, and point one level too high). It
+is off because `okf consume` does not read `parent`, so no payload ranks
+differently with it, while it moves the bytes of every bundle holding a
+heading-only section. One cost is known and not repaired: the index projects
+`parent` as a document number, so a segment id always renders there as
+unresolved (`parent: p1?`), even though the concept it names is in the bundle.
+
 ### The segmentation flags
 
 Nine rules are reachable from `okf build`, and since 2026-09-11 **all nine