Downstream dialect allowlists don't recognize OSSIE_SQL_2026

[jbonofre]

Background

#439 added OSSIE_SQL_2026 as a dialect in the core spec, and #440 added the matching value to the Python OssieDialect enum. Documents using OSSIE_SQL_2026 now pass model validation, but several downstream components hard-code dialect allowlists that predate this dialect and don't recognize it. As a result, fields/metrics expressed only in OSSIE_SQL_2026 are silently dropped or produce misleading warnings, even though the dialect is ANSI-SQL-compatible.

Affected locations

• converters/orionbelt/src/ossie_orionbelt/_common.py:41 — _SQL_PARSEABLE_DIALECTS tuple omits OSSIE_SQL_2026, so _select_sql_expression() drops such metrics from OBML export with a "no SQL-parseable dialect" warning.
• converters/snowflake/src/ossie_snowflake/converter.py:372 — _extract_expression() only recognizes SNOWFLAKE/ANSI_SQL, so matching fields/metrics are skipped from Snowflake export with a misleading warning.
• converters/databricks/src/ossie_databricks/_common.py:231 — pick_expression() only falls back through DATABRICKS/ANSI_SQL, returning None and causing the field/metric to be dropped from Databricks Metric View output.
• converters/wisdom/src/ossie_wisdom/ossie_to_wisdom.py:148 — _infer_dataset_dialect() / _pick_expression() never check OSSIE_SQL_2026, producing a spurious MISSING_DIALECT_EXPRESSION issue even though a fallback expression is still used.
• validation/validate.py:67 — DIALECT_MAP / SKIP_SQL_VALIDATION omit OSSIE_SQL_2026; it currently validates correctly only by accident, because dict.get()'s default happens to match the same None sentinel used for ANSI_SQL. This should be made an explicit mapping rather than relying on that coincidence.

Suggested fix

Treat OSSIE_SQL_2026 as ANSI-SQL-compatible in each of the allowlists/fallback chains above (mirroring how ANSI_SQL is handled), and add regression tests per converter covering a field/metric expressed only in OSSIE_SQL_2026.

Related

Follow-up from review of #440.