Update remaining converters for the flat (one-model-per-document) Ossie schema

Start by comparing the fixes in #407 and #417, then inspect the affected converter directories: databricks, orionbelt, ontology, gooddata, omni, honeydew, snowflake, salesforce, and polaris. Search their fixtures, source, tests, and test resources for the old semantic_model wrapper and run the relevant converter or snapshot tests. Done means all affected converters read and write the flat document shape, with fixtures and snapshots regenerated where needed.

Background

#383 moved the Ossie document schema to a single semantic model defined directly at the document root, dropping the semantic_model: [...] list wrapper. Since then, each converter has been fixed one at a time, only after its own CI happened to re-trigger and turn red:

• #407 fixed the Microsoft converter.
• #417 fixes the Sigma and NVIDIA GSF converters, plus the dbt and wisdom converters (which share the python/ package's OssieDocument model and would have broken the moment it was made to match the schema).

While working on #417, I found the same latent break in the remaining converters — none of them are currently red in CI, because their path-scoped workflows simply haven't re-run since #383 landed, but their fixtures/source still reference the old wrapper shape and will fail the moment something re-triggers their CI (the same way #416's license-header commit accidentally did for Sigma/NVIDIA GSF).

Affected

Confirmed via grep -rn "semantic_model:" over fixtures/source, and via gh run list showing no CI run for any of these since #383 (2026-09-16):

• converters/databricks (fixtures)
• converters/orionbelt (fixtures)
• converters/ontology (fixtures, plus the root examples/flights.yaml it vendors a copy of)
• converters/gooddata (fixtures)
• converters/omni (fixtures)
• converters/honeydew (source + tests)
• converters/snowflake (source)
• converters/salesforce (Java/Maven — source + test resources)
• converters/polaris (Java/Maven — source + test resources)

Suggested approach

Same pattern as #407 and #417: read/write the flat document shape (name/datasets/... at the root, no semantic_model: wrapper, no root-level dialects/vendors), update fixtures, and regenerate any snapshot tests. The Python converters can mostly follow the Sigma/NVIDIA GSF/dbt/wisdom diff in #417 as a template; the Java converters (salesforce, polaris) will need their own look since they don't share that tooling.

🤖 Generated with Claude Code