Shared audit_record and Codegen Composite-Type Support

Extend the domain entity JSON model so that any column entry can carry an optional include key. The generator collects all column-level includes and merges them into the entity's cpp.includes list before rendering.

Example:

{
  "name": "audit",
  "cpp_type": "utility::domain::audit_record",
  "include": "\"ores.utility/domain/audit_record.hpp\"",
  "is_composite": true,
  "description": "Provenance and audit trail for this record."
}

This is a purely additive change: existing models that omit include are unaffected. No global type registry is needed; the information lives in the model that uses the type.

Introduce the is_composite flag on a column. A composite column does not appear in the normal per-column mapping loop; instead the mapper template has a dedicated section that expands it by referencing a list of composite_sql_fields on the column definition.

{
  "name": "audit",
  "cpp_type": "utility::domain::audit_record",
  "include": "\"ores.utility/domain/audit_record.hpp\"",
  "is_composite": true,
  "composite_sql_fields": [
    {"sql": "modified_by",        "member": "modified_by"},
    {"sql": "performed_by",       "member": "performed_by"},
    {"sql": "change_reason_code", "member": "change_reason_code"},
    {"sql": "change_commentary",  "member": "change_commentary"}
  ],
  "description": "Provenance and audit trail for this record."
}

The recorded_at field is special: it requires a timestamp conversion and is sourced from valid_from not a same-named column. It stays outside the composite block as a mapper-level convention (or the composite can mark individual fields with a converter key).

Add a field-group model at:

projects/ores.codegen/models/utility/audit_record_field_group.json

with component_include: "utility" so the generator emits:

projects/ores.utility/include/ores.utility/domain/audit_record.hpp

Fields:

The generic stamp() template in handler_helpers.hpp currently detects audit fields by their individual names. Once all entities carry audit_record audit it can instead detect the composite:

if constexpr (requires { obj.audit; }) {
    stamp_audit(obj.audit, ctx, change_reason);
}

where stamp_audit is a small free function that sets the five fields. The existing per-field detection can coexist during the migration (opt-out once every entity is converted).

Entities are migrated one component at a time:

1. Remove the five individual audit columns from the entity model.
2. Add the composite audit column referencing audit_record.
3. Regenerate the domain struct and mapper.
4. Update any hand-coded references (e.modified_by → e.audit.modified_by).

Priority order: trading, refdata, iam, compute, analytics, dq. Each component is a self-contained PR.

street_line_1   std::string
street_line_2   std::string
city            std::string
state           std::string
country_code    std::string
postal_code     std::string
phone           std::string
email           std::string

These eight fields appear together on party and contact entities. Packaging them as utility::domain::postal_address removes eight boilerplate columns from every affected entity model and gives the type a name that expresses its intent. SQL storage remains flat; the composite mapper expands r.address.city = v.city etc.

The fields tenant_id, id (UUID surrogate key), and version appear on every temporal entity but are currently modelled as top-level columns rather than as a shared struct. Packaging them as utility::domain::entity_provenance would make stamp() cleaner (the tenant-id branch could detect obj.provenance rather than obj.tenant_id) and would group the three administrative columns that have nothing to do with business content.

This is lower priority because these columns are part of the primary-key and optimistic-locking machinery — tooling (sqlgen, repository helpers) relies on them by name. The rename and codegen changes required are larger in scope. Treat as a follow-up once audit_record and postal_address are established.