dbt converter loses derived metric time-context semantics in MetricFlow to Ossie conversion

## Problem

The MetricFlow → Ossie converter can silently lose time-context semantics from derived metrics.

For example, a month-over-month metric can use an offset input:

```yaml
- 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
```

The current converter flattens this into an ordinary Ossie SQL expression:

```text
(SUM(orders.amount) - SUM(orders.amount)) / SUM(orders.amount)
```

The `pre` offset semantics are lost. A top-level cumulative metric emits `CUMULATIVE_SEMANTICS_LOSS`, but a derived metric using offset-period inputs does not emit an equivalent warning.

## Expected behavior

The converter should report a `ConverterIssue` for derived metrics using non-portable time-context semantics, including `offset_window`, `offset_to_grain`, rolling windows, and grain-to-date semantics. The warning should identify the metric whose semantics were lost.

Strict mode could fail conversion instead of emitting a potentially misleading ordinary SQL expression.

Locate the MetricFlow-to-Ossie derived-metric conversion and the existing CUMULATIVE_SEMANTICS_LOSS handling. Review the converter tests for derived metrics, then cover offset windows, offset-to-grain, rolling-window, and grain-to-date inputs. Done means a ConverterIssue identifies the affected metric whenever these semantics cannot be preserved.

Written by the indexing model from the issue text.