Rate normalization (counts/s) is silently inoperative on timeseries data

[SimonHeybrock]

Problem

_normalize_to_rate in src/ess/livedata/dashboard/plots.py requires start_time/end_time scalar coords to compute the duration divisor. Timeseries data never carries these coords because _add_time_coords (in job.py:160) skips data that already has a time coordinate:

if 'time' in val.coords:
    return val  # start_time/end_time not added

As a result, enabling "normalize to rate" on a plot fed by timeseries data (or by WindowAggregatingExtractor over timeseries data) has no effect — _normalize_to_rate returns the data unchanged.

This means:

• A timeseries plot showing counts will always show raw counts, never counts/s, even if the toggle is on.
• A windowed aggregation (nansum) over timeseries counts data gives total counts in the window, but there is no mechanism to divide by the window duration to produce a rate.

Why this happens

The rate normalization and time-coord systems were designed around two non-overlapping paths:

• Histogram path: cumulative data → scalar start_time/end_time → _normalize_to_rate works
• Timeseries path: per-sample time coord → no start_time/end_time → _normalize_to_rate bails out

Possible directions

For WindowAggregatingExtractor: the window duration is already known (it's a constructor parameter and computable from the sliced time coord). The extractor could attach synthetic start_time/end_time from the windowed time range, or perform the division itself.

For FullHistoryExtractor (timeseries plotter): rate normalization is trickier since each point would need its own per-sample interval (similar to what CorrelationHistogramPlotter does with widths = times[1:] - times[:-1]).