Task: Move the pricing engine documentation onto the one contract

Every pricing engine choice and parameter carries the same documentation fields as an engine run setting, so one screen pattern reads both.

• Every pricing model, engine, pair and setting carries the contract's fields: label, help, description, default, format, introduced in, removed in, XPath and whether it changes the numbers.
• The extraction reads the ORE guide chapter and the ORE source, and records the ORE commit it measured.
• A missing entry shows the ORE name and a note on the screen.
• The vocabulary tables keep the mappings a person chooses from, and no longer hold the wording.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

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.

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 pricing parameter now carries the one contract: a label, a help line, the description from the ORE user guide, the value the examples use, the format, the release it entered and the XPath of the leaf. 646 setting rows cover every (type, scope, name) the guide describes, and 17 global rows cover the guide's global section and the pseudo-currency block the ORE source reads. The release each parameter entered is measured from the ORE release tags and kept in pricing_parameter_releases.json.

The vocabulary joins the rows by (scope, product type, name), so the Product pricing screen reads one field shape: 834 of 834 settings on the live API carry their documentation, and the Global parameters tab reads the globals array.

The models, the engines and the pairs joined the same contract: 956 pricing rows in all, with 25 models, 74 engines and 194 pairs documented on the live API. The vocabulary no longer serves its own wording: the settings carry no note, and the model, engine and pair text comes from the contract. The authoring journey reads help, not note.

One acceptance item remains, and it is now only dead data: the vocabulary tables still carry the wording columns (note on the pairs and settings, and the description and detail on the models and methods). The API no longer reads them. Drop the columns in a codegen change, so no later reader can take the wording from the wrong place.