The assets image publish function selects columns its table does not have

ores_assets_publish_images_from_dq_fn() reads a column called image_id from ores_assets_images_tbl and filters the same row by existing.key. That table has neither: its primary key column is id and its natural key is code. The function therefore aborts with column "image_id" does not exist at line 49, and the base bundle's assets.country_flags step fails with it.

Found on 2026-09-26 by the base-bundle publish, on the first run the publish path had ever taken. Every workflow start was failing on an unrelated defect in ores.workflow (see the sibling capture), so nothing downstream of a workflow had executed in this environment, and this one had no way to show itself. The provisioning treats Step 1 as best-effort and completes anyway, so the failure is reported in the step log rather than raised to the caller – which is why it needs a capture rather than a red test.

The fix is the two column names the table actually has – id and code – in projects/ores.sql/create/assets/assets_publish_from_dq_create.sql, around lines 84 to 106.

• The evidence is the provisioning run on Bring ores.iam to the clean standard: base.failed ... workflow failed at step 27 (assets.country_flags), with the failing query and the PL/pgSQL line number in the step log.
• projects/ores.sql/create/assets/assets_publish_from_dq_create.sql — the function.
• projects/ores.sql/create/assets/assets_images_create.sql — the columns it should read.

• No workflow can start once the system has an account — the defect that hid this one.