Task: Move the engine settings groups out of code

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

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

Delivered. Two reporting entities hold the groups and their settings, generated from their models and wired into the reporting service. A curation file carries what the constant held, row for row, and a generator writes the idempotent populate script with a –check mode. The BFF deletes GROUPS and reads both tables in stored order; the NATS subjects and row keys stay in a transport map keyed by group code. A group the data holds but the transport does not name is not offered, by design.

Verified. BFF engine 40 tests and web engine settings 55 tests pass, the build links, and the recreated environment holds 3 groups and 15 settings matching the constant, with the record page showing 6, 6 and 3 settings. Playwright proved the data drives the page: changing a row changed the API response with no code change, then the change was reverted.

The review added: the six handler permission codes of the new entities and the twelve of the value set handlers seeded, the generated shell scripts and recipe inventory committed, the reporting service component list regenerated, the value set trigger created or replaced, the diagrams regenerated, and a pricing fixture corrected to the type's words. The remaining local-check failures are the pre-existing ones: the synthetic component list, the synthetic protocol twin, and the strict ER parse warnings for tables that lack row level security, two of which are these new tables and the rest predate them.