feat: value forecast and departure risk in the schedule

[andig]

closes #163

Two optional request fields let the schedule weigh what the forecast and the vehicle may do instead of taking both as given. Absent, both reproduce the previous model, every stored case solves unchanged.

• p_departure per battery: probability of leaving in each time step, the remainder stays. p_a then values the state of charge the device is expected to leave with, so a charge that may be cut short is worth less than one already in. One term in the model, no new variables. The cost of charging planned after a departure is still counted in full, which leans the schedule early rather than making it exact.
• ft_err per time step: standard deviation of the generation forecast. The grid cost of a step is the mean over generation at ft - ft_err and ft + ft_err. The schedule is shared, only the grid split differs: a shortfall cannot raise the export, a surplus cannot raise the import. No scenario copies of the battery variables, no new binaries. Steps where export pays more than import stay at ft, since the pair is not locked by a direction binary there.
• The reported objective value follows the same accounting.
• tools/bench_risk.py runs the stored cases against main, then with a band of 20 % of ft growing with the square root of the lead time, and with a 30 % departure chance spread over hours 6 to 12 on every battery without discharge. Plain: 5.25 s against 5.25 s total. Band: 6.56 s, worst 016 from 0.26 to 0.90 s and 028 from 1.62 to 2.86 s, while 020 and 023 got faster. Departure: 4.26 s, nothing slower.
• evcc has to send the fields for any of this to take effect: departure from the session history, ft_err from the forecast provider bands or a default growing with the horizon.

🤖 Generated with Claude Code

[andig]

Split per feature: departure #184, forecast band #185.

🤖 Generated with Claude Code