Average long_time_metrics time curves over validation batches

[Adonyth]

Fixes #78

Inside Trainer.validation_loop, the time curves collected for long_time_metrics are merged with time_logs |= new_time_logs, which overwrites every key on each batch — the curves handed to plot_all_time_metrics reflect only the last validation batch. A two-batch toy example makes it concrete: if a metric's curve is 100.0 on batch 1 and 1.0 on batch 2, the logged value is 1.0 instead of the 50.5 average. This is inconsistent with loss_dict three lines below, which correctly accumulates loss_dict.get(k, 0.0) + v / denom.

The fix mirrors the loss_dict accumulation exactly, so the time curves become means over the same denom (the number of validation batches actually processed):

if k in long_time_metrics or "spectral_error" in k:
    for log_name, log_value in new_time_logs.items():
        time_logs[log_name] = (
            time_logs.get(log_name, 0.0) + log_value / denom
        )

Test note: Trainer isn't constructible without a full model/datamodule stack, so tests/test_trainer.py builds one via Trainer.__new__, sets only the attributes validation_loop reads, stubs rollout_model to return pre-made (y_pred, y_ref) batches, and captures what reaches plot_all_time_metrics. It asserts the captured full_VRMSE_rollout curve equals the mean of the two per-batch curves (and not the last batch's curve). The test fails on current master and passes with this change; ruff check / ruff format are clean under the pre-commit pinned v0.6.4. Happy to restructure the test if you'd prefer a different fixture approach.

Found while running an independent quantified-impact study of the benchmark's metric design; happy to adjust to maintainer preferences.

[payelmuk150]

This looks good.