[OSSIE][SIGMA] Add bidirectional Sigma Computing data model converter

[mattsenicksigma]

Summary

Adds converters/sigma, a bidirectional converter between Sigma Computing data model specs and Apache Ossie, following the same structure/tooling as the dbt and NVIDIA GSF converters (uv, the apache-ossie pydantic models).

• A real tokenizer + recursive-descent parser + ANSI SQL renderer for Sigma's spreadsheet-style formula language (ossie_sigma.sigma_formula), covering ~30 functions and all operators with nested-call support — not a regex classifier. Every expression always preserves the original Sigma formula verbatim in a new SIGMA dialect entry, guaranteeing lossless round-tripping regardless of translation coverage, alongside a best-effort ANSI_SQL translation.
• Sigma ⇄ OSI mapping for datasets, fields, relationships (including Sigma's two column-addressing schemes — modeled column id vs. raw inode-<file>/<PHYSICAL_COLUMN> warehouse references), and model-level metrics, with native Sigma ids preserved via custom_extensions so re-export reuses stable ids rather than minting new ones.
• Controls and named/static element filters are intentionally not modeled as OSI concepts (no portable equivalent — see converters/sigma/LIMITATIONS.md §1) but round-trip byte-for-byte via custom_extensions.
• Adds SIGMA to OSIDialect/OSIVendor (python/src/ossie/models.py), the core-spec schema/docs (core-spec/spec.md, core-spec/osi-schema.json), and a Sigma column in expression_language.md's cross-tool mapping tables.
• Fixes two small pre-existing gaps found while validating output against the repo's own tooling (documented in LIMITATIONS.md): core-spec/osi-schema.json was missing root-level dialects/vendors properties already present in the pydantic model, and validation/validate.py didn't skip SQL-syntax checking for SIGMA the way it already does for MDX/TABLEAU/MAQL.

See converters/sigma/LIMITATIONS.md for a full, honest accounting of design tradeoffs, known gaps (relationship resolution edge cases, table-calculation functions with no portable form, cross-dataset metrics with no Sigma equivalent, etc.), the testing strategy, and a self-assessment of likely review concerns.

Opening as a draft to gather early feedback on the approach (particularly the relationship-resolution strategy and the SIGMA dialect/vendor enum additions) before finalizing.

Test plan

• cd converters/sigma && uv sync && uv run pytest — 50 tests pass (formula parser unit tests, directional conversion tests, byte-for-byte round-trip tests for two synthetic fixtures, and a real-world-input test against examples/tpcds_semantic_model.yaml)
• Verified sigma-to-osi output validates cleanly against core-spec/osi-schema.json and validation/validate.py for both fixtures
• Re-ran python/, converters/dbt/, and converters/gsf/ test suites to confirm the shared enum/schema changes don't regress existing converters
• Feedback from a committer on the relationship-resolution approach and whether the SIGMA enum additions need a dev@ discussion or can proceed via normal PR review (see LIMITATIONS.md "Assessment: likelihood of upstream approval")

🤖 Generated with Claude Code