Task: Implement unified SQL template

Create sql_schema_create.mustache as the unified SQL template that replaces both sql_schema_table_create.mustache and the SQL portion of sql_schema_domain_entity_create.mustache. Add table model-type support to generator.py and profiles.json. Define 10 _table.json models for all refdata entities in the new format. Verify that running codegen.sh regenerate --component refdata-table --profile sql produces zero logical diff against the current SQL files in projects/ores.sql/create/refdata/.

• sql_schema_create.mustache exists at projects/ores.codegen/library/templates/.
• generator.py recognises *_table.json files as model type table.
• profiles.json maps sql profile to sql_schema_create.mustache for table model type.
• 10 *_table.json model files exist in projects/ores.codegen/models/refdata/.
• codegen.sh regenerate --component refdata-table --profile sql --dry-run prints all 10 output paths.
• Running the actual regeneration produces zero logical diff (only template name comment changes) against the current repo SQL files.
• All four both tenant-scope entities (currency, currency_market_tier, monetary_nature, rounding_type) generate IN (p_tenant_id, ores_utility_system_tenant_id_fn()) validation logic.
• party_id_scheme generates the check ("max_cardinality" is null or "max_cardinality" > 0) constraint correctly.
• Site builds cleanly.

Round 1 addressed in commit d32ea690a.

Implementation complete. Files created/modified:

projects/ores.codegen/
  library/
    templates/
      sql_schema_create.mustache           new unified template
    profiles.json                          added "table" to sql profile
  models/refdata/
    book_status_table.json                 new (system scope, display_order)
    contact_type_table.json                new (system scope, display_order)
    currency_table.json                    new (both scope, nullable coding_scheme, image_id)
    currency_market_tier_table.json        new (both scope, default=g10)
    monetary_nature_table.json             new (both scope, default=fiat)
    party_id_scheme_table.json             new (system scope, check_constraints)
    party_status_table.json                new (system scope, display_order)
    party_type_table.json                  new (system scope, display_order)
    purpose_type_table.json                new (system scope, display_order)
    rounding_type_table.json               new (both scope, default=Closest)
  src/
    codegen/
      generate.py                          added "table" to --profile all safety check
      manifest.py                          added refdata-table component
    generator.py                           is_table_model(), get_model_type(), resolve_output_path(),
                                           table special processing, sql_check_constraints pre-render

Key design decisions:

• _table.json suffix convention analogous to _entity.json, _domain_entity.json, etc.
• Three-way tenant scope (system / both / tenant) replaces the binary system_tenant_validation flag; pre-computed as boolean flags in generator preprocessing for Mustache consumption.
• Check constraints pre-rendered as a single string (sql_check_constraints) in generator preprocessing to avoid pystache whitespace issues with adjacent section tags.
• refdata-table component added to manifest for parity verification; replaces refdata once Task 4 (migration) is complete.
• Notify triggers for table model types are NOT generated by sql_schema_create.mustache — they continue to be generated by the existing sql_schema_notify_trigger.mustache from domain entity models.

Parity result: all 10 entities produce zero logical diff. Only cosmetic differences:

• Template name in the AUTO-GENERATED comment header (sql_schema_table_create.mustache → sql_schema_create.mustache).
• Validation function comment wording (explanatory text, not SQL logic).