A planned battery export kept moving 15 minutes later with every run. At
07:49 the plan exported at 08:00 and 08:15; the run at 08:00 exported at 08:15
and 08:30, although nothing in the forecasts had changed.
Genomes are run-relative: gene 0 controls the slot the run starts in. Clients
such as Node-RED send the previous `start_solution` back unchanged, so after a
slot boundary every decision in it is read one slot too late. The warm start is
seeded as exact copies and local neighbours, and when an export 15 minutes
later scores almost the same, the shifted genome survives and becomes the next
warm start. The internal energy management run reused its last solution the
same way.
Solutions now carry `start_solution_datetime`, the start of the slot gene 0
controls, and requests accept it back. Before seeding, the battery and EV blocks
drop the elapsed slots and repeat their last gene. A warm start that starts
after the run, or whose control slots have all elapsed, is ignored. When a
request omits the datetime but its `start_solution` equals the last solution of
this server, that solution's start is used, so existing clients are fixed
without changes. Appliance genes index per-run start slot lists that cannot be
rebuilt for the earlier run and stay as they are, validated as before.
