Stop posting the write-only enable flags back at the inverter

[Poshy163]

Follow-up to #274, from testing on #267. Two commits: the second is the important one.

What #267 turned up

@dragon2611 probed setTimeChargeBySn directly and established what the two enable flags actually do:

sent	effect on the inverter
1 / 0	schedule active, scheduled discharging off
1 / 1	both schedules enabled
0 / 1	scheduled discharging only
0 / 0	switches the inverter to self-consumption

And that getTimeChargeBySn answers 0 for both however the inverter is set — he wrote 1 and read back 0 half a minute later, across a schedule rewrite, a switch to Self-Consumption and a switch back to Time-Based Control. They are write-only.

The bug that follows

main reads those flags, keeps them in the snapshot, and sends them back on every write. On a system whose read is always 0/0 that means every schedule change Home Assistant makes posts 0/0 and asks the inverter to leave timed control. The lockout then reads the same zeros and reports a self-consumption mode — which by then is true, because we put it there.

The only thing that kept it from being worse is the bug that hid it: with the read always 0/0, is_time_based_control_active() is always False, so the lockout refused every write. It jammed far more often than it fired. Removing either half on its own makes things worse, so both are fixed here.

The fix

• The read is no longer part of the snapshot. Nothing can replay it.
• Every write sends a value that came from the user — this request first, then what was last recorded — and is refused when neither has an answer, rather than choosing a working mode on someone's behalf.
• The two switches are the record. They restore their published state on startup and hand it back to the coordinator, and read unknown rather than off until they have one.
• A recorded 0/0 is a real request — it is how the API is told to run self-consumption — so it still locks the time-based controls, and the switches stay available to undo it (that is the first commit).
• Backup mode is untouched. There gridCharge/ctrDis are ordinary read-write fields, live-probed in Move scheduling onto the periodic API, with staged edits and Apply #274, and behave exactly as before.

Also confirmed from his probes: an empty period list answers 6001 and a missing one 10001, so the both-lists rule stands — and the error now names the workaround, which is to give the side you don't want a period and turn its switch off.

Consequence worth flagging

setbatterycharge carries only the charge flag, so on periodic systems both switches must be set once before any service call is accepted. Documented in services.yaml and in the Predbat section of the README.

Tests

554 → 568, 100% coverage, ruff clean. TestWriteOnlyEnableFlags pins the regression directly: a system answering 0/0 while running a schedule gets 1/0 posted back, not the zeros. Plus a switch change beating the stored answer, refusal on unknown and half-known state, a flag-only change still reaching the API, and the normaliser stripping the read. TestSwitchStateSurvivesRestart covers restoration.

[Poshy163]

@CharlesGillanders need this to go for a b3 release

[CharlesGillanders]

@CharlesGillanders need this to go for a b3 release

Something odd happening with GitHub mobile, no request for a review of this and adding myself as a reviewer doesn't seem to give me an option to review?!? Can you please request a review and I can do so?

[Poshy163]

Cool, done, see how that goes