Task: Bring ores.synthetic to the clean standard

ores.synthetic passes the Component Clean Standard for a component of kind Entity.

• Every checklist item that applies to a component of kind Entity passes, with its evidence recorded on the task.
• Every item that does not apply is recorded as not applicable, with the reason.
• Every generator defect found is fixed at its source, with a regression test.
• ores.synthetic is listed in COMPONENTS_UNDER_TEST, and check_component_drift.py --all passes.

Work the Component Clean Standard in its section order, one entity at a time, and record each item's result in the table below.

1. Baseline and inventory (B01 to B05). Record the baseline before any edit.
2. Models (M01 to M10).
3. Protocol (P01 to P06).
4. Generation (G01 to G06).
5. Wiring and data (W01 to W04).
6. Shell (S01, S02).
7. Structure and hygiene (H01 to H03).
8. Verification (V01 to V08), ending with the registry question.

• The baseline dry run is reproducible with check_component_drift.py --component synthetic --dry-run. Before any model edit it listed 106 changed and 41 created files; after the group model and the profile bind it listed 107 and 46. The extra five are the parameter-value entity's shell unit, its recipe and its eventing integration test, which the bound profile's physical space enables, plus the generated root CMakeLists.
• PR #2138 (feature/remove-the-legacy-qt-remnants) has merged. It removed the dead presentation keys from the same seven synthetic models. This branch rebased onto that trunk with no conflicts, and the drift check still reports the regenerated tree unchanged.
• The database recreates from scratch and the fleet serves. All four synthetic ctest suites pass against it, and check_component_drift.py --all reports no drift with synthetic registered.
• Final verification runs on the trunk at origin/main 640d760090, after a rebase with no conflicts and a whole-tree build. The rebase raised the ORES_ENV_VERSION to 24, so compass env configure was re-run before the database recreate.
• The regime error-handling question (61 throw sites in this component) belongs to the house-wide capture, not to this pass.
• Diagrams, corrected. An earlier entry on this task claimed synthetic had no component diagram. That was wrong: each part carries projects/ores.synthetic/<part>/modeling/{component_overview.org, ores.synthetic.<part>.puml, ores.synthetic.<part>.png}, and the overview's Diagram section points at the image. Two real defects were behind the confusion. The automated section of all three diagrams predated this branch's regeneration, so it was stale, and the hand-authored section was empty in all three – a skeleton of empty boxes, which H01 forbids. Both are fixed in this pass: the automated pass was re-run, and the manual pass fills the boxes with the API and draws the relationships the automated pass cannot infer, with 458 hand-authored lines for api, 574 for core and 250 for service, and 51, 29 and 27 relationship edges respectively. Each render was read, not merely re-run, and a second capture reports no changes, so the sentinel contract holds. The capture had a defect behind the missing members: a line counted as a method whenever it held a parenthesis, so tenant_id vanished from all nine generated entities. A parenthesis now means a signature only when it precedes any equals sign. The shell part, ores.shell.synthetic, had no modeling/ directory at all and now carries the full set. The ER diagram (projects/ores.sql/modeling/ores_schema.puml) is fully generated with no sentinel section, and re-running plantuml_er_generate.sh returns synthetic's tables byte-identical: the churn belongs to iam and ore, and the same run shows the model's AUTO-GENERATED FILE - DO NOT EDIT MANUALLY banner leaking into a rendered note. Both are ores.sql's to fix and are not carried here.
• Repo-wide scale of the diagram gap, measured after H05 made it explicit. Of 90 component *.puml files, 82 have a rendered image beside them and only 9 carry any hand-authored content. So roughly 81 diagrams are bare skeletons, including those of ores.iam and ores.compute, the two components already listed in COMPONENTS_UNDER_TEST. H01 has been unmet across the tree, and H05 now states the requirement so the gap is visible. Closing it is a house-wide task, not synthetic's.
• One generator defect found by the build is fixed at source: the eventing test's FK-chain seed variable was named after the FK column, so a chain step whose column repeated an earlier step's column declared the same variable twice. It now takes the ancestor entity's name, with a regression case in test_eventing_seed_plan.py.
• A second template-level finding is recorded, not fixed: generated domain, eventing, protocol and handler types carry no export macro, in synthetic and in refdata alike, so it belongs to a house-wide template change.
• The former exception is closed at its source. The eventing integration test for ir_curve_generation_config_process_parameter_value is re-enabled, and two defects behind it are fixed.
  • The test seeds its definition parent through a parent_seed block that selects a VASICEK catalogue row. The insert trigger requires the definition's process type to match the config's, and the config generator always emits VASICEK, so the generic catalogue seed could pick a definition the trigger rejects.
  • The table's party policy now lets a session with no party restriction through. The row carries no party_id of its own – its scope comes from the parent config – so the join alone returned nothing for a party-less session, and the writer could not read back the row it had just written. The generated party policy and the reporting risk_report_config policies of the same shape carry the same passthrough. The diagnosis is recorded in build/audit_synthetic/value_row_rls_diagnosis.md.

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.