Task: Document the curve segment and quote leaves

Every leaf a curve segment or its quotes holds carries its words in the ORE parameter contract, from the ORE guide chapter that documents it, so a screen can draw the leaf from data.

• Every segment leaf the extractor finds has a contract row: the 15 leaves the guide's parameterisation chapter does not cover are curated from the curve configuration chapter, with the line that documents each one.
• The one quote leaf the guide stated in roman type, `InflationCurves/Quotes`, has a contract row without being curated by hand, because the extractor reads that typography.
• The curation states, per entry, the source, the reference into the guide, the curator, the date and the reason, as the row builder requires.
• The regenerated dataset publishes the new rows, and a query counts them, before and after.
• The local checks that compare the dataset and the value sets with their sources pass, and the artefact populate is the generator's.
• A segment leaf is recorded once, under the path the document holds it at, and not beside the block that holds it.

Three pieces, in this order.

1. Read the guide's second typography. The parameterisation chapter writes an entry as `\item Name: text`, and the curve configuration chapter writes some of them as `\item {\tt Name}: text`. The extractor's item pattern accepts the first and not the second, so 14 leaves reach the contract without words while the guide does say them, and 8 more were taking text from an unrelated chapter that happened to use the same name. Accepting `{\tt Name}` recovers the 14 and gives the 8 their own family's words.
2. Record a segment once. A parser that dispatches on the children of a block (`Segments`) was walked twice: once under the block, where the document puts them, and once beside it, where it does not. The beside-the-block copy put 11 wrong paths into the contract. The alternatives belong to the block, so the class's dispatch list is walked at the class's own path only when the class holds no dispatch block.
3. Curate what the guide states only in prose. The 15 segment leaves the guide explains in sentences and XML listings, never in an item, get a curation entry each: a label, one sentence, the guide line that says it, the curator and the date. The curation file is the mechanism the row builder already reads and the local check already names; it did not exist because the guide covered every other leaf.

The rows then flow as they always do: the extractor writes the terms, the row builder turns them into parameter rows, and the dataset generator writes the artefact.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

• The gap was the extractor, not the guide. The curve configuration chapter documents the segments it invites a person to write, so the words existed; the extractor's item pattern did not accept `{\tt Name}:`, and its block walk recorded a dispatched segment twice.
• The words were already half there. 11 segment leaves had rows, because their names also appear as items elsewhere. The remaining 15 are the leaves the guide explains in a sentence or only shows in a listing, so the curation says which sentence, with the line.
• One leaf name covers two segments. `YieldCurves/ProjectionCurve` is curated once and serves both the simple segment and the average OIS segment, because the guide gives the meaning once and the average OIS section refers to the simple segment for it.
• The guide misnames one leaf. The weighted average section lists `Weights` as the weight of the second curve where the schema and the parser declare `Weight2`, so the curation states the second weight and its reason says why the name differs.
• A path defect was found and is not this task's. Four published smile paths name a `Dimension` their parent does not declare, because the extractor attributes a block to the class of the last call that names its variable, and `ParametricSmileConfiguration::fromXML` reuses `n` for three blocks. Filed as task Retire the curve parameter paths the schema does not declare.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Every leaf a curve segment holds now carries its words in the contract, taken from the ORE guide chapter that documents the segments.

Three changes got there. The extractor reads the guide's roman item form, which recovered 14 leaves and gave 8 more the words of their own family instead of an unrelated chapter's. The extractor records a dispatched segment once, under `Segments`, which took 11 wrong paths out of the published contract. And the 15 segment leaves the guide states only in prose or in a listing are curated from the line that says each one, in a curation file the row builder already read.

Against the recreated and provisioned environment: the contract holds 253 curve leaves, up from 235, and 26 of them are segment leaves, up from 11. No published curve path names an element its parent does not declare, where 11 did. The four parameter suites that read the contract pass, and the two checks that compare it with its sources pass.

What is not done, and is not this task's: 155 curve leaves still have no words, in the `Report`, `BootstrapConfig` and other blocks, and four smile paths and one volatility path are wrong for a cause of their own. The latter is a task.