[DBT] Map config.meta onto Ossie custom_extensions instead of dropping it

[georgea-tk]

Summary

config.meta is silently dropped when converting an MSI manifest to Ossie — dimensions, entities, measures, metrics, and semantic models can all carry arbitrary presentation/vendor metadata (e.g. a LookML group_label or value_format), and none of it survives the conversion. Both ends of the mapping already exist: MSI exposes config.meta as a dict, and Ossie's Field/Metric/Dataset/SemanticModel all define custom_extensions with an open vendor_name string.

This maps a non-empty config.meta onto one custom_extensions entry (vendor_name="DBT", data=json.dumps(meta)) wherever it's currently dropped. Empty/absent meta still produces no custom_extensions.

Two things intentionally left out of scope, per the issue:

• Round-tripping through ossie_to_msi — open question in the issue on whether that's wanted.
• The equivalent drop in converters/snowflake (Follow up on OSI ai_context and custom_extensions mapping in snowflake yaml #111) — a separate PR, since fixing either alone doesn't get metadata all the way through.

vendor_name="DBT" follows the schema's own example; happy to change it if maintainers prefer COMMON or something else.

Related Issues

Fixes #303

Checklist

Specification

• N/A — no spec change

Ontology

• N/A

Converters

• Converter logic in converters/ is updated to reflect spec or ontology changes
• New tests added under the converter's test directory

Validation

• N/A

Documentation

• N/A — internal mapping, no user-facing doc surface changed

Examples

• N/A

Tests

• All existing tests pass — ran full converters/dbt suite locally, 106 passed
• New functionality is covered by tests — dimension/entity/measure/metric/semantic-model config.meta, plus empty and absent meta

Compliance

• ASF license headers present — no new files, only edits to existing licensed files
• No third-party dependencies added

[QMalcolm]

Thank you for putting this together! What has been done thus far, looks good 🙂 The PR body mentions that

Round-tripping through ossie_to_msi — open question in the issue on whether that's wanted

I think round-tripping would be desirable. I'd appreciate that being added before approval ❤️ If you disagree, let me know, and we can discuss it more and perhaps proceed as is.

[georgea-tk]

Added — round-tripping now works via ossie_to_msi._config_from_custom_extensions, the inverse of the forward mapping: it finds the DBT-vendor custom_extensions entry (if present) and reconstructs config.meta from it. Wired into the same call sites the forward direction touched (entities, dimensions, the dataset itself, and metrics — RATIO's synthetic numerator/denominator sub-metrics intentionally don't inherit it, since they have no origin of their own).

Verified an actual MSI -> Ossie -> MSI round trip preserves config.meta intact, not just via the new unit tests.