Task: Publish the ore parameters through DQ

The ore parameters reach the system tenant through system_core and each tenant through base, so a tenant user reads the documentation of the engine settings.

• The two datasets publish in dependency order into the system tenant and into a tenant.
• No populate script writes the ore parameter tables.

(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 ORE parameters (610 rows) and their value domains (5 rows) are two DQ datasets. One generator writes them. Two publish functions write them into the system tenant through system_core and into each tenant through base. The four direct populate scripts are gone. After a provisioning of Acme, the system tenant and the Acme tenant each hold 610 parameters, and the engine settings screens read the documentation of all 15 settings.

The tests that need an ore parameter seed five of their own and no longer read the real data. The double bundle membership is a stopgap, and the capture "One source for reference data that the system and each tenant read" tracks the choice of one source.