Task: Serve the engine settings

A person reads the documentation of each engine setting and reads and changes the settings of a named configuration through the BFF, by the same checks as the rest of the reporting screens.

• The reporting service answers the engine settings, its three parts, the ore parameters and their value domains.
• The Member role reads and writes the settings and reads the documentation, and deletes stay with the administrative roles.
• The BFF routes read, create, change, delete and list the history of a configuration, and refuse a bad value before the service sees it.

(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 reporting service now answers the engine settings, its three parts, the ore parameters and their value domains. The four engine settings models had their messaging, eventing and history addresses switched off, so the work was to remove that section and generate the C++ surface: protocol, handler, registrar, service, event, history provider and shell commands. The registrar of the service now registers the handlers of these six entities, and the ore parameters had a generated handler that nothing registered.

The Member role reads and writes the engine settings and reads the ore parameters and their value domains. A person who may edit a report may therefore edit the settings it binds. Deleting stays with the administrative roles.

The BFF serves the configurations at /api/reporting/engine-settings: the list, one configuration with its three groups and the reports that bind it, the documentation of each setting, the history, and the writes. A group is written alone against the version of its part, and the service makes the next version of the central row. The BFF refuses a value that its setting does not accept, so a thread count of zero never reaches the service. The wording of each setting comes from its ore parameter, so the BFF holds only what a setting is and never what it means.

The ore parameters and the file types are rows of the system tenant. A tenant other than the system tenant sees none of them until a provisioning step copies them. That gap is older than this change and affects the file types too.