feat(octopus): configurable minimum-reward threshold for saving-session auto-join

[chalfontchubby]

Summary

Fixes #4593, per gcoan's review
(now tracked as #4595).

The saving-session auto-join loop reads octopoints_per_kwh only to compute a display rate, never
to decide whether the event is worth joining, so a zero-point event is join-attempted exactly like
a real one. This matters today because the Octopus integration currently puts national Power Up
(free electricity) events into the Power Down available_events set at 0 p/kWh - described in
#4548 point 5 and BottlecapDave/HomeAssistant-OctopusEnergy#1820.
Predbat tries to join each one and the integration rejects it, and since the join result isn't
checked (#4548 point 8, separate issue, not touched here) each rejected attempt still fires a false
"joined" notification.

An earlier version of this PR added a fixed octopoints_kwh <= 0 guard. gcoan pushed back: the
real root cause is the integration miscategorising events, and a hardcoded skip is the wrong shape

• a user may also want to skip a genuine, low-value Power Down session they don't consider worth
  the disruption, not just the zero-reward ones. He suggested a configurable minimum-value threshold
  instead, defaulting to today's unfiltered-at-zero behaviour.

Fix

Adds octopus_saving_session_min_octopoints_per_kwh (apps.yaml, default 0). An available
event is only auto-joined when its octopoints_per_kwh exceeds this threshold - the default of
0 reproduces the exact behaviour of the original fixed guard (skips <= 0), while raising it lets
a user also filter out genuine but low-value sessions. null keeps its existing meaning (rate not
reported, default rate applies) and is never checked against the threshold - only an explicit
reported rate is gated.

This mirrors an invariant that already existed on the planning side: the joined_events loop that
builds octopus_saving_slots already requires saving_rate > 0. The guard was simply missing (and,
at the fixed value, insufficiently flexible) on the join side.

Documented in docs/energy-rates.md, and added (commented or not, matching each template's existing
octopus_saving_session_octopoints_per_penny state) to every inverter's apps.yaml template.

Test plan

• test_saving_session_zero_rate_skip (test_saving_session.py) - unaffected, still covers
  zero/negative/positive/null rates against the default threshold
• New test_saving_session_min_octopoints_threshold - four sub-cases: default threshold still
  allows a moderate reward, a raised threshold blocks a lower reward, a raised threshold still
  allows a reward that exceeds it, and a reward exactly equal to the threshold is skipped
  (exceeds, not meets)
• ./run_all --quick passes (743 tests)
• ./run_pre_commit passes

🤖 Generated with Claude Code

[gcoan]

@chalfontchubby see my comment on the original issue.

I don't think a guard on octopoints rate being zero is correct and the premise for it causing session join rejections is incorrect.

I proposed a better more flexible solution

[chalfontchubby]

@chalfontchubby see my comment on the original issue.

I don't think a guard on octopoints rate being zero is correct and the premise for it causing session join rejections is incorrect.

I proposed a better more flexible solution

Ok - happy to leave it to you

[gcoan]

Hi Rik @chalfontchubby I'm more than happy for you to make the code changes, I could make them, but I'm nowhere near as familiar with the automated test framework so I'd struggle with that part

My suggestion on #4593 was to deliver the filter the OP suggested by a configurable 'min saving session amount'. Perhaps in the future Octopus will do zero value saving sessions; the Eclipse saving session was almost that !; and by having a configurable threshold then predbat users can choose what S/S to autojoin based on battery cycle cost, charge/discharge losses, etc.