Proposal: metric additivity (additive / semi-additive / non-additive) in the core spec

[harrydevforlife]

Problem

In the current core spec (core-spec/spec.md), a metric is only name, expression, description, datatype, ai_context and custom_extensions. There is no way to declare how a metric may be aggregated across dimensions.

For fully additive metrics (SUM(revenue)) and clearly non-additive ones (COUNT(DISTINCT user_id), ratios) a consumer can often infer behaviour from the expression. But semi-additive metrics cannot be inferred: SUM(balance), inventory levels, or daily-active snapshots are summable across users/regions but must not be summed across time (you want last / first / average over the period instead). Today the only options are vendor-specific custom_extensions or ai_context hints, neither of which is portable or enforceable by query engines.

Proposal

Add optional, portable additivity metadata to the Metric object, e.g.:

- name: account_balance
  expression:
    dialects:
      - dialect: ANSI_SQL
        expression: SUM(accounts.balance)
  additivity: semi_additive   # additive | semi_additive | non_additive
  non_additive_dimensions:
    - field: accounts.snapshot_date
      window: last            # last | first | min | max | avg

Prior art: dbt/MetricFlow non_additive_dimension (with window_choice and window_groupings), Cube, SSAS semi-additive measures (LastNonEmpty, etc.).

Open questions

1. Should additivity be explicit, or derived from non_additive_dimensions being present?
2. What should the default be when omitted (unknown vs. additive)?
3. Should non-additive metrics declare the components needed for correct re-aggregation (e.g. numerator/denominator for ratios)?
4. How does this interact with is_time fields and time-grain handling?

Happy to help draft a PR if there is interest.