Task: Make the parameter data model the source of valid values and rules

One parameter model states a parameter's control and its rule, and every screen reads it from there. A parameter's allowed values, its bounds, its pattern and its catalogue live in the value set tables and nowhere else. The per-pair kind and options columns go, because the value set now says the same thing once instead of on every pair that takes the setting. The engine run settings reach the same contract, so the Setup parameters stop carrying a second copy of their control in the group settings table. The screens keep one source, the write path keeps one enforcement point, and a build check fails when a parameter loses its set.

• The value set tables are the only place that states a parameter's control and its rule. No screen, server or seed restates an allowed value.
• The 15 settings whose set said text although the guide lists their choices state an enumerated or boolean set, from a curation entry that names the guide as its source. The settings that stay text say in the set why they are text.
• ores_analytics_pricing_pair_settings_tbl holds no kind and no options column. The C++, the protocol, the SQL, the TypeScript, the shell recipe and the seed are generated from the model without them.
• usual_value stays, because the pricing screen shows the usual setting of a pair, and it states a value and not a rule.
• Every Setup parameter that the engine run settings screen draws has a value set and a link, and that screen draws its control and checks its value from the set through the same fields the pricing screen reads.
• A check in build/scripts/local_checks.py fails when a parameter a screen draws has no value set, when a set breaks its own rule, or when a per-pair override column returns.
• The build, the four test suites, the drift checks and a live environment prove the behaviour: a change to a set changes the screen's choices, a refused value names its set, and the ORE export and import still roundtrip.

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 parameter data model is the one source of a parameter's control and rule, on both configuration screens, and a check holds it.

• The value set tables state every parameter's allowed values. 266 parameters a screen draws carry 1 link each, and the 224 sets state an enumerated list, a catalogue, a range, a regular expression, a switch or text.
• The Setup scope joined the contract. Six sets state the fifteen engine run settings' controls, the group settings table lost its copy, and the screen draws and checks from the set through the same fields the pricing screen uses.
• The per-pair kind and options columns are gone from the model, the SQL, the C++, the protocol, the TypeScript, the shell recipe and the seed. The compiler found the last reader, a hand-written proposal check, and it asks the store's own function now.
• Fifteen settings the guide states a vocabulary for stopped being free text: thirteen carry the guide's list, and two stay text with the reason in the set.
• build/scripts/check_parameter_value_sets.py runs in the local gate. It fails on a parameter a screen draws with no set, on a set whose own kind cannot hold its rule (a floor above its ceiling, an empty or duplicated list, an unregistered catalogue, a patternless expression), on a bound or a list written as a column check on an engine settings part, and on a read of the retired per-pair column. Each was proved by breaking it and reading the failure. The seeded script is compared with its sources exactly by generate_value_sets.py --check, which owns that test.
• The engine run settings' rule lives only in the set: the part tables lost their column checks and carry a guard that asks the verdict function, and the ORE run document codec lost its own list of observation models.
• ore_parameter_settings check reports the 266 parameters the screens draw, the engine run settings among them, and answers OK when every one names a set of a kind its domain takes. It refuses to judge a database whose ORE parameter contract is not published, and says so.

Proven live on a recreated, provisioned environment: adding a value to setup.observation_model in the database added it to the screen's choices, and raising the floor of setup.n_threads moved the bound the server enforced, with no server change. A group write below the floor was refused. A pricing engines document exported and previewed with 0 rows added, changed or removed and 0 issues. A parameter write outside its set was refused by the trigger, naming the value, the setting and the set. The retired columns appear in no reply.

Not done here, and stated rather than hidden: the Setup block's 54 input-file parameters have no set because no screen draws them; three of them name a catalogue vocabulary and want a later task. Calibration stays text until the ORE enumeration can be read from the source, because the guide's list omits a value the seeded documents write. The pending provenance columns on the row are the story's own task, not this one.

Commits on the branch, in order: the inventory, the Setup sets, the guide's choices, the engine settings screen reading the set, the retired per-pair columns, the gate, and the proposal check.