Retain past manual import/export rate overrides so cost_today and the savings baseline price consumed energy correctly

[Jonno12345]

Problem

Using the Octopus free weekend hours, I manually set the pricing for those two 30 min slots to 0, to allow predbat to calculate correctly. However, I noticed in the totals, it was still showing as if I hadn't nil rated it.

Manual import/export rate overrides (select.predbat_manual_import_rates / manual_export_rates) were dropped as
soon as their slot passed. Two things went wrong as a result:

• predbat.cost_today (and cost_today_import / cost_today_export / cost_today_car) fell back to the base tariff
  for energy that had already been consumed at the overridden price, so the running total for the day was wrong.
• The yesterday savings baseline in calculate_yesterday() shifts the live rate table back a day, so it never saw the
  override either, while cost_yesterday (read back from the recorded cost_today history) did. The two sides
  disagreed on any day with an override.

Octopus saving sessions and Axle VPP sessions don't have this problem because they persist in the API session list
after the slot ends. This brings manual overrides in line with them.

Fix

• manual_rates() keeps import/export overrides for 24 hours after their slot (today and yesterday). Other manual
  items (manual_soc, manual_soc_max, manual_load_adjust) are unchanged and still drop past slots.
• Past slots are written back as an absolute date (2025-12-19 11:00=0.0) instead of Fri 11:00=0.0, so once the
  weekday has passed they don't resolve to next week. get_override_time_from_string() accepts the absolute format.
• New manual_rate_same_slot() helper matches stored entries by resolved slot, so the plan card can still clear or
  replace a past slot using its weekday label.
• Retained overrides also show on the published rate charts and the plan HTML for the slots they cover, since those
  read the same rate tables.

Tests

• New manual_rates_history test: retention for import and export, flow-through into rate_import at today's minutes
  and at yesterday's negative minutes (where the savings baseline reads), clearing by weekday label, replacement
  without duplication, dropdown options, and the 24-hour cut-off.
• Two new absolute-date cases in override_time.
• Existing manual_* / rates / saving / yesterday tests pass; black, ruff, cspell and markdownlint clean.

Docs

Added a paragraph to docs/customisation.md describing the retention and the absolute-date form shown in the
selector.

[chalfontchubby]

Not a firm pushback - thinking out loud. I thought we should be fetching octopus information that would correctly show free hours without manual overrides - but that is going from memory.
Many people seem to use manual price overrides to coerce predbat's behaviour rather than reflecting reality - which is not ideal for sure but might lead to some other complaints.

[Jonno12345]

Not a firm pushback - thinking out loud. I thought we should be fetching octopus information that would correctly show free hours without manual overrides - but that is going from memory. Many people seem to use manual price overrides to coerce predbat's behaviour rather than reflecting reality - which is not ideal for sure but might lead to some other complaints.

I fully agree that integration is the best in practice for this use case and should be added, but it's not the only reason I've ever overridden (a while ago USwitch offered free electricity for a period too and to my knowledge this isn't integrated in a way predbat could work with). Potentially with other providers too, but I don't know for sure.

My counter would be that if a user overrides the rate they're paying/importing at, it doesn't make sense that the costing in the entity doesn't account for this. As a user, I told it these hours are free, but ended up over accounting by nearly £2 and there's no way to get the real value I programmed in.

I do get your point, it's a change to previous behaviours if someone is anticipating that to add up with the original tariff values, but it feels like the wrong way to achieve it when you can specifically force an action or set a favoured battery level, which don't have the side effect of messing up costing.

[chalfontchubby]

I agree that if you manually override costs, then it should be reflected in calculations.