Task: Apply the standard to the pricing engine configuration

The pricing engine configuration screens follow the configuration screen standard, with the documentation contract, the reach, the history, the Simple and Advanced switch, the related configurations and the import.

• The record page has Details, Global parameters, Products, Reports and History, in that order.
• Products is a tree of the configuration's product types by asset class beside the product, and the product takes the rest of the width.
• The product states what it is, its asset class and its instrument, then a Model group and an Engine group. Each group states what a model or an engine is, names the choice, gives its description and lists its parameters.
• Every model, engine and parameter description comes from the server's vocabulary, not from a screen literal. A description the server does not hold says so.
• Global parameters lists the parameters that apply to the whole document, each with its documentation collapsed under it.
• Reports lists the reports that bind the configuration and states the reach rule.
• History is the shared timeline, served by the history read.
• The page is read-only. Edit and the product Edit open the save dialog, which states the difference and asks for a change reason.
• The import follows the standard: the parse on the server, the findings, the difference and the review.

The work sits on one branch and goes out as one PR.

1. The BFF joins the product type to its instrument code to carry the asset class, adds the reach to the document read, and allows the configuration's history type.
2. The page draws five tabs through useTabs, so the address holds the tab.
3. The Products tab draws the tree by asset class and the workbench, with the model and engine groups and the parameter documentation from the vocabulary.
4. The tests cover the details, the product workbench, the reach, the global parameters and the write actions.

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

The owner signed the screen off after testing it on the clean environment.

The screen reads the parameter value sets from the model in one lookup: the product editor draws `Training.Sequence` and `Pricing.Sequence` as five-value combos, `Training.BasisFunction` as the seven curves, flags as true and false, integers as whole numbers. The product tree names each product in words, the add-product dialog asks for the model and the engine and reports only that product's findings, and a save returns the document with its reports so the dialog closes and a stale second save cannot happen.

The check function that guards a parameter runs as its owner, so the analytics service can write a configuration without owning the value set tables.

Evidence: Playwright on the live screen (product combos, globals flag, add and save), `ore_parameter_settings check` returning OK on 251 of 251, the web and BFF suites green, and the database recreated and provisioned from a clean state for the test.