fix(wisdom): read OSSIE_SQL_2026 metric expressions

[christianeu-db]

Summary

#439 added OSSIE_SQL_2026 to the core spec and #440 added it to the Python
OssieDialect enum. This PR adds awareness to the wisdom converter.
_pick_expression() fell back only through the dataset dialect and then
ANSI_SQL, so a field or metric expressed solely in OSSIE_SQL_2026 raised a
spurious MISSING_DIALECT_EXPRESSION issue.

OSSIE_SQL_2026 is ANSI-SQL-compatible, so this treats it as an
ANSI_SQL-equivalent fallback:

• ossie_to_wisdom.py adds an OSSIE_SQL_2026 branch to _pick_expression(),
  so an OSSIE_SQL_2026-only field or metric is exported without the spurious
  issue.
• Five regression tests cover a field-only and a metric-only OSSIE_SQL_2026
  expression, the ANSI_SQL and native-dialect precedence over it, and a
  genuinely unusable dialect that still reports MISSING_DIALECT_EXPRESSION.

_infer_dataset_dialect() needs no change: like ANSI_SQL, OSSIE_SQL_2026 is
not a native connection dialect, so a dataset expressed only in it already
resolves to the ANSI-compatible connection. wisdom_to_ossie.py only writes the
connection's own dialect on the way out, so the reverse direction is untouched.

This is a partial fix. #442 lists five call sites across the converters and
validation; databricks (#446), orionbelt (#443), and snowflake (#447) are
merged, and this one covers the wisdom converter.

Related Issues

Part of #442.

Checklist

Sections that this change does not touch (Specification, Ontology, Validation,
Documentation, Examples) are left unchecked.

Converters

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

Tests

• All existing tests pass (pytest / CI green)
• New functionality is covered by tests

Compliance

• ASF license headers are present on all new source files
• No third-party dependencies are added without PMC/IPMC approval

[kayemkim]

Ran it merged into current main through the wisdom CI steps on 3.11 to 3.14: green, 32 tests against 27. On main a field and a metric carrying only OSSIE_SQL_2026 export fine but raise two MISSING_DIALECT_EXPRESSION issues, and on this branch the export is byte-identical with no issues. The fallback order matches what #447 did for snowflake, and it merges with #455 without conflict. LGTM.

[jbonofre]

LGTM!

Adding OSSIE_SQL_2026 as a fallback after the native dialect and ANSI_SQL is right.

The lookup order is covered by the new tests, including the no-match case that still reports MISSING_DIALECT_EXPRESSION. Great work!

One note, non-blocking: expressions that exist only in OSSIE_SQL_2026 now convert without any warning, so the output SQL may not be valid on the target dialect. That seems like the intended tradeoff here, but it may be worth documenting.