feat: r_departure, the chance a device leaves per time step

[andig]

closes #163

A vehicle may leave before the horizon ends. Today the schedule values only s[-1], so a charge planned for tomorrow morning counts as much as one in the car now. One optional field per battery lets the schedule weigh that risk. Absent, the model is unchanged and every stored case solves as before.

API

• r_departure: per-step probability mass that the device leaves during that step, sum at most 1. The remainder is the chance it stays past the horizon. A mass, not a hazard or a CDF: it is the objective weight directly, it stays well defined with varying dt (the first evcc step is a partial slot), and session-history histograms already come as masses. Validated: no negative entries, sum ≤ 1, length matching dt, else 400.
• Shown in the README example and the OpenAPI schema, generated client carries RDeparture.

Model

• p_a values the expected state of charge at departure, sum_t r_t * s[t] with the remainder on s[-1], instead of s[-1] alone (_soc_value_weights). One objective term, no new variables or rows.
• Once the cumulative mass reaches one the device has certainly left: charge and discharge bounds are zero from there on (_present). Without that the cost neutral tie break put free surplus into a gone vehicle (p_E = 0 with charge_before_export), and the bounded steps now leave the model in presolve.
• Charging planned after an uncertain departure still costs in full, only its value is weighted. The schedule leans early rather than being exact in expectation, on purpose.
• A p_demand past a certain departure is a conflicting request: the demand penalty wins and fills the vehicle before it leaves, at real cost. The caller cuts the demand where it cuts the presence.
• The reported objective follows the same accounting.

Measured, tools/bench_departure.py on the stored cases

variant	total	note
main	5.20 s
branch, no r_departure	5.18 s	rows and columns unchanged
30 % departure over hours 6 to 12, every battery without discharge	4.19 s	020 and 028 solve faster
certain departure at hour 12, the 13 cases that reach it	3.47 s → 2.45 s	with the presence bounds; 023 0.69 → 0.04 s, 028 0.69 → 0.38 s

Tests: tests/test_risk.py (expected value accounting, certain departure stops charging, validation, length mismatch), stored case 029-departure-risk-charges-early.

Caller side: evcc-io/evcc#34422 builds r_departure from the session history as a time of day hazard per weekday and weekend slot, blended with a 24 h half-life prior, and converts it to the per-step mass. On a real instance with 248 sessions of a daytime car that gives, plugged in on a Monday at 13:00, 33 % gone by 15:00 and 92 % by Tuesday 10:00; the raw history agrees (44 % of its midday plug-ins were gone by 15:00). Forecast uncertainty is the separate #185.

🤖 Generated with Claude Code