Two-sample rate derivation

The raw telemetry plane returns cumulative counters, and the companion document
describes the two-sample pattern for converting them to rates. Where this API is
concerned the same rules apply to any counter it passes through, with two
additions specific to the operational plane.

Counters may reset without warning. A controller restart re-baselines every
cumulative counter. In the raw plane this appears as a decrease between samples
and must be treated as a reset rather than as negative traffic. In the Prometheus
plane it is handled for you — the emitter detects the reset, re-baselines
silently, and increments bng_metric_baseline_reset_total. Alarming on that
counter is the cheapest way to see controller restarts in monitoring.

Prefer the retained series over hand-rolled sampling. If a rate is available
from /throughput/recent, /metrics/query_range, or a Prometheus scrape, use it.
Those paths already implement the reset handling, the gap semantics, and the
step alignment described earlier. Hand-rolled two-sample arithmetic is
appropriate for values this API exposes only as cumulative totals — the
per-interface byte counters on /dataplane-stats, for instance.