Task: Model the curve configuration entities

Curve configuration is typed entities in the component that owns curves, so a run references a curve recipe rather than shipping curveconfig.xml.

• Every entity family the taxonomy records for curveconfig has a model and an owner.
• A curve entity resolves its conventions, calendar, day counter and index by foreign key, not by string.

(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.

Delivered by Round trip the curve configuration, which modelled every section of curveconfig.xml as typed entities in ores.refdata, the component that owns curves, and proved them with a whole-document round trip over the corpus.

Acceptance met: every curveconfig entity family has a model owned by ores.refdata; a curve resolves its day counter, segment type and index by foreign key, and its conventions and calendar through validation functions, so a name the database does not hold is refused.