Add forecasting models and metrics

[Irozuku]

Summary

Adds the models and metrics that make ForecastingTask usable. Last of the four branches implementing forecasting.

Four models, all sharing an unusual contract for DashAI: they learn no mapping from features to a target, because there are no features. The only input is a date column, and everything the model knows comes from the history of the series itself. So train reads the series out of y_train and ignores the feature matrix, and predict treats its argument as a request for a length rather than as data to score, returning one value per row continuing from where training ended.

That is exactly why the windowed route through TimeSeriesWindowConverter and RegressionTask exists alongside this one: it turns history into real features, which is the only way an ordinary regressor can help.

ForecastingTask -> models   : ARIMA, ExponentialSmoothing, NaiveForecaster,
                              SeasonalNaiveForecaster
                -> metrics  : MAE, MAPE, MSE, MedianAbsoluteError, R2, RMSE,
                              SMAPE, ExplainedVariance
                -> splitters: RollingOriginSplitter, TemporalHoldoutSplitter

---

Type of Change

Check all that apply like this [x]:

• Backend change
• Frontend change
• CI / Workflow change
• Build / Packaging change
• Bug fix
• Documentation

---

Changes (by file)

• DashAI/back/models/forecasting/base_forecasting_model.py: new. ForecastingModel(BaseModel) with COMPATIBLE_COMPONENTS = ["ForecastingTask"], the shared series reader, the horizon reader, joblib save and load, and a guard that refuses to forecast before training.
• DashAI/back/models/forecasting/naive.py: predicts that the series stays where it last was. No dependency, nothing to tune.
• DashAI/back/models/forecasting/seasonal_naive.py: predicts that each season repeats the one before. season_length = 1 makes it the plain naive forecast.
• DashAI/back/models/forecasting/arima.py: wraps statsmodels.tsa.arima.model.ARIMA, exposing p, d and q as optimizable orders.
• DashAI/back/models/forecasting/exponential_smoothing.py: wraps statsmodels Holt Winters, exposing trend, seasonal and season_length.
• DashAI/back/metrics/regression_metric.py: add ForecastingTask to COMPATIBLE_COMPONENTS. One line, and it is what makes MAE, MSE, RMSE, R2, median absolute error and explained variance available to forecasting without reimplementing any of them.
• DashAI/back/metrics/forecasting/mape.py, smape.py: new percentage error metrics.
• DashAI/back/initial_components.py: register the four models and two metrics.
• tests/back/models/test_forecasting_models.py, tests/back/metrics/test_forecasting_metrics.py: new. 24 and 11 tests.

---

Testing (optional)

• Do a forecasting training workflow with all models

---

Notes (optional)

One deviation from the spec, which had MAPE and sMAPE as forecasting only metrics. They subclass RegressionMetric instead, so they serve both routes to a forecast. Restricting them to the native task would have left a user on the windowed route unable to use the metrics most natural for the thing they are doing.

MAPE divides by the true value, so it is undefined wherever that value is zero. Those rows are skipped rather than allowed to produce an infinity that would swallow the score, and an all zero series reports nan. sMAPE exists precisely because that limitation is real: it divides by the average of both values, stays defined at zero, caps at 200 percent, and does not punish over forecasting more than under forecasting.

Both statsmodels wrappers suppress the warning about assuming evenly spaced observations. That assumption is deliberate here, so the warning says nothing the model does not already document.

Seasonal ARIMA is not exposed: it would need three more orders, and ExponentialSmoothing with a seasonal component covers seasonality more legibly. Prophet remains out of scope for now, being a heavy dependency and the model most likely to need the exogenous variables that are a separate task.