fix(elecprice): do not shorten the forecast by the source's own lag

The price series went flat towards the end of the horizon: a constant value
repeated for the last hours, exactly as long as the day-ahead source was behind.

The ETS extrapolation is appended after the last known price, but its length was
computed as `prediction.hours * slots_per_hour - covered_slots`, and
covered_slots is zero once the last known price lies before the run start. The
forecast therefore spanned prediction.hours measured from the last known price
rather than from now, and ended that much too early. Callers reading past that
point got the last record held constant.

With SMARD published up to 2026-09-08 23:45 and a run at 2026-09-09 13:00, the
forecast covered 09-09 00:00 to 09-12 00:00 while the horizon needed 09-12
13:00: 52 quarter-hour slots of flat price, right inside the trailing window the
terminal value curve is derived from.

The length is now measured from the last known value through to
`ems_start + prediction.hours`, which reduces to the previous formula whenever
the source is current. Both the electricity price and the feed-in tariff
provider had the same calculation.

CHANGELOG.md

@@ -241,6 +241,13 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - `ElecPriceSMARD` now distinguishes a lagging publication from a broken response. A window the
   source cannot serve yet reports the latest value it does have, instead of claiming the response
   contained no usable prices.
+- A day-ahead source that lags no longer shortens the price forecast by its own lag. The ETS
+  extrapolation is appended after the last known price, but its length was measured from the run
+  start, so a source that had not published the current day yet left exactly that lag uncovered at
+  the end of the horizon. Callers reading `elecprice_marketprice_wh` or `feed_in_tariff_wh` past
+  that point saw the last value held constant - a flat price in precisely the trailing window the
+  terminal value curve is derived from. The length is now measured from the last known value
+  through to `ems_start + prediction.hours`.
 - A weather-API outage no longer takes the whole prediction update with it.
   `PVForecastAkkudoktorLocal` raised on the first failed Open-Meteo request, and
   `PredictionContainer.update_data` re-raises whatever an enabled provider raises, so every