Task: Draw the curves tab of the curve configuration

(Describe what user-visible-or-internal change this task produces.)

1. Replace the nineteen section tabs with one Curves tab, drawn as the product pricing screen draws its products: a rail on the left, a workbench on the right.
2. Group the rail by the section that declares each curve, because the section decides the entry's table and its leaves even though it is not what a person looks for.
3. Name the sections that hold nothing once, at the foot of the rail, rather than giving each a tab that opens empty.
4. Draw the chosen curve in the workbench: its identity apart from its parameters, its documentation, the filters and the elements it holds.
5. Test the tabs, the grouping order and a rendered curve.

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.

• Why the section is the group and not the tab. The 89 curveconfig*.xml files ORE ships fill a median of three sections, the smallest one and the largest sixteen; the environment's four stored configurations fill one. A tab per section therefore opens mostly empty, and asks a person to find the chapter before the curve. As a group it still says which family a curve belongs to, which is what decides its table and its leaves.
• The prototype is the argument. Curve configuration sections draws the shape over a one-, four- and sixteen-section document, and this task draws the page from it.
• The identity is drawn apart from the parameters. A curve's CurveId and CurveDescription live on curve_definition, which every family shares, and the rest live on the section's own table. The workbench draws them as two cards, as a product's workbench draws the product apart from its model and engine settings.
• The standard needs an amendment. The configuration screen standard states one tab per section. This task breaks that rule deliberately, and the amendment is "one tab for the collection, and the section is the group inside it". It belongs to the story that owns the standard, Make every configuration screen follow one standard, and is raised there rather than changed around.

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.

The curve configuration page now draws Details, Curves, Used by and History. The Curves tab is the product pricing shape: a rail of the configuration's curves grouped by the section that declares each, with a count on every group, a filter that matches a curve's name, its description or its section, Expand all, and the sections that hold nothing named once at the foot. The chosen curve is read beside the rail: what it is, its identity, its parameters with their documentation and filters, and the elements it holds.

The nine browser tests cover the four tabs, the grouping order, a rendered curve's value and words, a leaf the contract does not document, a flag read as Yes or No, the elements a curve holds, the reports that bind the configuration and the history. The nested collections of a curve are still named and not drawn, which is the task of their own.