fix(dbt): warn on non-portable metric semantics

[fanruan-tuco]

Summary

MetricFlow time-context semantics such as cumulative metrics, windows, time spine behavior, and offset-period inputs cannot be represented faithfully in Ossie. This change emits NON_PORTABLE_METRIC_SEMANTICS instead of silently producing a lossy conversion.

It also checks derived and ratio dependencies recursively, including cases such as:

- name: month_over_month_growth
  type: derived
  type_params:
    expr: (cur - pre) / pre
    metrics:
      - name: revenue
        alias: cur
      - name: revenue
        alias: pre
        offset_window:
          count: 1
          granularity: month

Fixes #317

Validation

uv run pytest -q in converters/dbt: 103 passed.

[jbonofre]

@fanruan-tuco can you please rebase and resolve conflicts? Thanks!

[jbonofre]

This new branch records a NON_PORTABLE_METRIC_SEMANTICS issue but doesn't change control flow: the next line (expr = self._resolve_metric_expression(...), unchanged) still runs and emits the lossy expression regardless.

I verified against the example in the PR (month_over_month_growth = (cur - pre) / pre): the emitted expression is (SUM(orders.amount) - SUM(orders.amount)) / SUM(orders.amount), always 0. The output document carries no marker of the problem, only a side-channel entry in result.issues: a caller that doesn't check issues ships an always-zero metric silently.

Should this branch continue/skip emitting the metric (like CONVERSION_METRIC_DROPPED above) instead of failing through?

[jbonofre]

This only special-cases CUMULATIVE. A DERIVED/RATIO metric that depends on a CONVERSION-type metric return False here (not portable-safe, just unrecognized), so convert() proceeds into _unresolve_metric_expression, which raises an unhandled RuntimeError ("Unexpected CONVERSION metric in expression resolver") and aborts conversion of the entire manifest.

Maybe worth adding a MetricType.CONVERSION case here too.