Task: Move the lookup artefact tables onto domain models

No artefact table comes from the lookup template, and the template is retired.

• The fifteen tables are generated by the canonical template from domain_entity models.
• sql_schema_artefact_create is deleted once no model uses it.

The table belongs to the model of the data it stages, so each of the fifteen gets an owning model in the component that owns its rows, with :ores.sql.schema.domain_entity_artefact_create.enabled: true and an * Artefact columns section, because the staging shape is not a projection of the entity. Twelve had no model at all and are new; party_roles and asset_classes are the two that needed more than the flag.

The task description says these tables came through ores.codegen.lookup_entity models. They did not: no *_lookup_entity.org file exists in the tree or in its history under these names, so the tables were orphaned output that no run rewrote. The files were the real target and the premise was stale.

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.

• asset_classes was the one table that needed a redesign rather than a flag. It had no entity but did have an asset_class_messages operation model over a hand-written repository and service, and the joined list it served had no consumer outside its own handler. The hand-written pair and the operation model are retired; the entity generates the table, its staging table and the read and write stacks in their place.
• The refdata account_types codelist collides with the IAM account type of a login account: the shell menu name is the entity plural and has no override, so two components generated a menu named account_types. The codelist is renamed trading_account_type, which names what it classifies – a trading account, by whose activity it carries – and clears the menu.
• The first pass overwrote the IAM account_types shell recipe, because the codelist briefly claimed the same menu. Regeneration restored it from the IAM model; the drift check is what caught it.
• The per-entity ores_refdata_validate_<entity>_fn functions the orphan tables carried are not generated by the entity template. Nothing called them, so they go with the orphans.

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: no DQ artefact table comes from the lookup template, and the template is gone.

Measured at c55e014e49, with cd projects/ores.sql/create/dq && grep -h "Template:" *_artefact_create.sql | sed 's/.*Template: //' | sort | uniq -c: 119 tables from sql_schema_domain_entity_artefact_create, 9 from the junction template, and 0 from sql_schema_artefact_create. The template, its literate source, its entry in get_schema_template_mappings and the four codegen tests that rendered it are deleted.

Verification, all at c55e014e49, after merging main:

• ./compass.sh build with the linux-clang-release-ninja preset: exit 0.
• ./compass.sh test run --preset linux-clang-release-ninja: 93 of 93 suites passed, 0 failed, 825 s.
• ./projects/ores.sql/test/run_tests.sh: 52 files, 512 tests, PASS.
• ./compass.sh check --exclude-heavy: 40 of 41. The failure is the web class's agile-tree read timing out under parallel load; it passes alone in under a second.

The pgTAP run needs an active tenant that people set up. A db recreate leaves only the system tenant, and CLI provisioning leaves the Acme tenant in bootstrapping until the provisioning wizard runs its complete_provisioning step, so the four isolation files fail on their own fixture before it is activated. Completing it the way the wizard does, with ores_iam_mark_tenant_active_fn, is what they need; this branch touches none of the tables they assert on.