Salesforce converter: translate OSI metric expressions and validate field references

Start with the metric export work in #402 and the expression-language work in #222, then map the stated SQL expression scope to Tableau syntax and reference validation. Add unit and schema coverage for combinations, nulls, duplicates, empty inputs and zero denominators; done means clear metric-named errors for unsupported expressions, missing fields and ambiguous references, with results validated in Tableau Next.

#402 adds metric export but leaves expression translation and field-reference validation for follow-up work. This issue covers that work, including the reference validation requested in #399.

The goal is to convert supported SQL expressions into Tableau formulas so users can reuse their OSI metric definitions without maintaining a separate Tableau expression for each metric.

Initial scope

• Aggregates: SUM, AVG, MIN, MAX, COUNT(field) and COUNT(DISTINCT field).
• Arithmetic: +, -, *, /, parentheses and numeric constants.
• Conditional logic: CASE WHEN, comparisons, AND, OR and NOT.
• Null handling: COALESCE, NULLIF, IS NULL and IS NOT NULL.
• Numeric functions: ABS, ROUND, CEIL and FLOOR.

Support combinations of these functions, including expressions such as:

SUM(orders.amount * (1 - orders.discount))

SUM(CASE WHEN orders.status = 'paid'
         THEN orders.amount ELSE 0 END)

SUM(orders.profit) / NULLIF(SUM(orders.revenue), 0)

Expected behavior

• Translate supported SNOWFLAKE and ANSI_SQL expressions into Tableau syntax.
• Resolve references against declared datasets and fields, including quoted identifiers.
• Validate types and aggregation rules while preserving the original calculation’s meaning.
• Fail with the metric name and a clear explanation for unsupported expressions, missing fields or ambiguous references.
• Test combinations, nulls, empty inputs, duplicates and zero denominators. Validate results in Tableau Next alongside unit and schema tests.

Date/time functions, string functions, casts, references to other metrics, window calculations and level-of-detail calculations can follow as separate milestones. COUNT(*) also needs separate handling to establish which dataset’s rows are being counted.

Source-object discovery, missing-field enrichment and deployment are outside this issue. The extension-preservation fixes identified in #402 should remain there.

i’ll take this on through follow-up PRs built on #402. The implementation should align with the expression-language work in #222.