Refresh the stale ER diagram from its generator

Regenerate projects/ores.sql/modeling/ores_schema.puml from projects/ores.codegen/plantuml_er_generate.sh and review the result on its own branch, then wire a drift check so it cannot fall behind again.

The committed diagram does not match its own generator. Running the generator on 2026-09-26 produced 26 hunks against the checked-in file: table notes in iam, trading and elsewhere, and column order changes. None of it is schema-shape change; it is the generator's newer description and ordering conventions that the committed file predates. The generated file is 383 lines away from what the tool produces.

The gap is invisible today because no gate compares the diagram with its source. The ER generator has a parse, render and diagram stage, and plantuml_er_parse_sql.py --validate-only guards the SQL, but nothing checks that .puml equals a fresh render.

The work is not a one-line regeneration. The diff is large and mostly unrelated to any one component, so it belongs on its own branch with its own review, not inside a per-component clean-up story. The capture exists because the ores.database clean-up needed one table's description preserved and declined to drag those 383 lines into its diff.

• projects/ores.codegen/plantuml_er_generate.sh — the three-stage pipeline.
• doc/knowledge/architecture/plantuml_er_diagram_conventions.org — the conventions the committed file predates.

• Component Clean Standard — item H01 makes a current diagram part of a clean component; the component that raised this capture could not satisfy that item without the churn.