feat(prediction): model PV recapture beyond the export limit during Freeze Export

[chalfontchubby]

Summary

Follow-up to #4538 (merged) - reworks the fix properly instead of disabling Freeze Export for FoxESS/FoxCloud outright.

Root cause, not FoxESS-specific: Predbat's Freeze Export model forced charge_rate_now = 0 unconditionally and fell through to the general export-limit clip, so any inverter with PV genuinely exceeding load + the hardware export limit had that surplus modelled as clipped/lost - regardless of whether the real hardware actually routes it into the battery instead. inverter_can_charge_during_export already modelled exactly this recapture behaviour, but only for active Force Export windows (export_limit_now < 99.0) - it was never wired into the freeze path (export_limit_now == 99.0).

Confirmed on real hardware two ways:

• FoxESS "Feed-in First" prioritises load, then export, then the battery - PV beyond load+export charges the battery rather than being clipped (FoxESS Freeze Export mode predicts no battery charge, but the battery does charge #4207).
• Sigenergy under active Force Export with a capped export limit: battery charged at 1.3kW while still exporting at the 1kW cap (live test, documented in the Predbat requested "Freeze Discharging" despite switch.predbat_set_export_freeze = False #4464 investigation notes) - same physics, already correctly modelled for that window type.

Fix: Freeze Export now gets its own branch in prediction.py (mirrored in prediction_kernel.cpp) - the battery is never actively discharged (still a genuine freeze), but once PV alone exceeds what load + the export limit can absorb, the genuine spillover charges the battery (capped at the overflow amount and the battery's own charge rate) instead of being clipped, when inverter_can_charge_during_export allows it. SoC still holds flat whenever the export limit alone can cover the surplus.

FoxESS/FoxCloud's support_discharge_freeze reverts to True (same hardware via two connection methods) now that this is correctly modelled instead of disabled - Freeze Export is offered again and correctly predicted for both.

Kernel

• KERNEL_PARITY_REVISION/PK_PARITY_REVISION bumped 6 → 7.
• All six platform binaries cross-rebuilt via zig (build_kernel_cross.sh).
• ./run_all --test kernel_parity passes - the random/clipping sweeps randomise set_export_freeze and include a dedicated export_freeze scenario, so the new branch is genuinely exercised, bit-identical between Python and C++.

Baselines regenerated

Freeze Export now recaptures more energy than before in scenarios where PV exceeds the export limit, so some plans shift to use it more (strictly an improvement in the underlying model's accuracy, never a regression in capability - freeze could previously never do worse than clip everything, now it can do better).

• coverage/cases/random_results.json regenerated via ./run_random - self-consistent (0 diff on re-compare).
• coverage/cases/predbat_debug_pre_saving1.yaml.expected.json regenerated (one of the two debug-case regression fixtures picked a different, cheaper plan).

Docs

inverter_can_charge_during_export's apps-yaml.md entry updated to cover Freeze Export, not just Force Export. Also added it to APPS_SCHEMA (config.py) - it was previously read via get_arg with no schema entry at all.

Test plan

• New test_freeze_export_recapture_beyond_limit in test_optimise_solar.py - PV well above load+export limit charges the battery when inverter_can_charge_during_export=True, stays flat (old behaviour) when False. Directly exercises Prediction.run_prediction(), isolated from the optimiser's window search.
• test_foxess_support_discharge_freeze_matches_foxcloud (test_inverter.py) updated: both now True.
• ./run_all --test kernel_parity passes.
• ./run_all --quick passes (full suite, including regenerated baselines).
• ./run_pre_commit passes.

🤖 Generated with Claude Code