[Audit] Document non-additive measures in fact_uptime and fact_interval_data

## Context

Two measures in the mart layer are non-additive but are not documented as such. A consumer who SUMs either of these across rows will produce a meaningless or incorrect number, and nothing in the current schema warns them.

- `fact_uptime.uptime` — a ratio (0–1). Summing uptime fractions across ports or dates produces a number with no business meaning. The correct aggregation is a weighted average (weighted by commissioned time).
- `fact_interval_data.avg_value` — an average. Averages cannot be re-aggregated by SUM; re-averaging averages without weighting by observation count also produces incorrect results.

In a semantic layer context this matters doubly: if these measures are defined as `SUM` in MetricFlow, every metric that touches them will silently return wrong numbers.

## Acceptance criteria

- [ ] `fact_uptime.uptime` column description explicitly states it is a ratio (0–1), is non-additive, and documents the correct aggregation method (weighted average, weighted by commissioned minutes or equivalent)
- [ ] `fact_interval_data.avg_value` column description explicitly states it is a pre-aggregated average, is non-additive, and documents what the correct downstream aggregation is
- [ ] The semantic layer metric definitions for any metric derived from these measures use the correct aggregation type (not `SUM`) — or a note is added to this issue if no semantic model currently references them
- [ ] A `dbt_utils.accepted_range` test (or equivalent) is added to `fact_uptime.uptime` asserting values are between 0 and 1 inclusive, as an additional guard against bad data producing out-of-range ratios
- [ ] No SQL changes to the mart models are required — documentation and semantic layer config only (unless the semantic layer definitions need correction)