fix(solis): apply slot events immediately so Predbat's read-back sees them

[springfall2008]

Problem

With Solis Cloud, Predbat sometimes logs that a discharge-time write failed, but the value then reaches the inverter anyway.

Predbat writes the slot time to select.predbat_solis_<sn>_discharge_slot1_start_time and polls the select for about 20 s (write_and_poll_sleep 2 s × INVERTER_MAX_RETRY 10). Since #4875, SolisAPI.select_event only queues the event. The queue is drained at the start of run(), and ComponentBase only calls run() once a minute (seconds % 60 == 0). So the select keeps its old value past Predbat's poll, and Predbat logs Trying to write … didn't complete. On the next cycle the queue drains, the handler updates the schedule, and run() writes the value to the inverter.

A second, smaller problem: read_and_write_cid reports a failure whenever the write call errors, even if the read-back it has just taken already shows the new value. That happens when the SolisCloud relay applies a write but its reply times out.

Changes

• Slot events are applied immediately. Slot times (select), slot SoC and power (number) and slot enables (switch) of an already-discovered inverter now run their handler on the calling loop.
  • Those handlers only change the in-memory charge_discharge_time_windows and make no API calls, so the loop-affinity problem fix(solis): queue entity events for the component loop #4875 fixed doesn't apply. The cloud write still happens in run().
  • Everything that calls the cloud is still queued: storage mode, reserve and the inverter-wide settings. So are slot events that arrive before discovery.
• The slot handlers publish only the slot controls. A new publish_slot_entities(inverter_sn) holds the slot loops, moved unchanged apart from indentation out of publish_entities(). Handlers call it instead of republishing every entity from the calling thread.
• read_and_write_cid checks the read-back first. If the read-back matches, the write counts as a success, and the log notes the error reply.
• Refused slot writes are rolled back (V2, pass 2). If the inverter refuses a slot enable or time write, restore_refused_slot_write sets the schedule back to what the inverter holds (cached_values). The select then shows that value, and Predbat writes again on its next execute.
  • It only rolls back while the schedule still holds the value it tried to write. Slot events are now applied from another loop, and a newer request that arrives during the write must win.
  • Pass 1 keeps retrying every minute: rolling back a failed "clear this slot" write would switch the slot back on. So do V1, which writes one combined register, and slot SoC/current, which the inverter can legitimately adjust.

Tests

Seven new tests in test_solis.py:

• a slot select, number and switch are applied and published without draining the queue
• a slot event before discovery is still queued (guards existing behaviour)
• read_and_write_cid treats a landed-but-errored write as a success
• a refused slot time and a refused slot enable are restored to the inverter's value
• a newer request that arrives during a failed write is kept. I mutation-checked this one: removing the compare-and-set makes it fail.

test_rate_setpoints_do_not_drift_with_battery_voltage now calls publish_entities() after the slot handler. It had relied on the handler republishing the inverter-wide max_charge_power, which run() still does every minute.

• ./run_all --test solis passes. It failed on the five behaviour tests before the fix, and passes on unmodified main.
• ./run_all --quick passes
• pre-commit passes

🤖 Generated with Claude Code