docs(inverter-setup): fix Sigenergy Freeze Charging forced-import bug

[chalfontchubby]

Summary

discharge_cut_off_state_of_charge was hardcoded to 100 for Freeze Charging, which is always above current SoC by construction. Sigenergy have confirmed this is a firmware bug on their side: setting this above current SoC makes the inverter actively import from grid to reach it, even with grid_import_limitation at 0kW. Not a trickle in practice - observed several kW, continuing unattended until the target is reached (see #4375 for the full live-hardware investigation).

• Pin discharge_cut_off_state_of_charge once, when Freeze Charging starts, to current SoC minus a small (1pp) margin - not a hardcoded value, and not continuously re-pinned.
  • Why once, not continuous: Freeze Charging's own contract already means SoC can only stay flat (grid covers any shortfall) or rise (solar surplus still charges the battery) while discharge is genuinely blocked - so a one-time pin at freeze-start remains valid for the whole session. Continuously re-pinning to live SoC would actively undermine "frozen": it relocates the anchor to wherever SoC has already drifted to, rather than correcting back to it, so real drift (e.g. the inverter's own standby losses) would never actually get corrected.
  • Why the small margin: the confirmed mechanism only ever corrects one way (import if SoC reads below target). Pinning to the exact SoC reading makes ordinary sensor noise asymmetric - a low reading costs a real, if tiny, import; a high reading costs nothing. The margin absorbs normal jitter without needing to track it.
• Apply the same one-time-pin treatment to Freeze Discharging's charge_cut_off_state_of_charge (mirrored: current SoC plus a small margin), instead of leaving it hardcoded to 0. Not itself vendor-confirmed the way the discharge side is, but 0 is always below current SoC by the same structural shape as the confirmed bug - and pinning costs nothing, since it still fully blocks charging either way. This also restores what jamiekets independently proposed in Configure Predbat to control Sigenergy SigenStor inverter #2077 back in November 2025 (both cutoffs pinned together) - the version that made it into the shipped docs only kept half of that.
• Add an explicit note explaining the firmware bug, why the pin must be fixed rather than tracking, and why the margin exists - linking Sigenergy: Freeze Charging template still forces grid-import at full price (discharge cutoff=100 in Maximum Self Consumption) — related to #2872 #4375 and the wider community setup thread (Configure Predbat to control Sigenergy SigenStor inverter #2077, where Sigenergy's own acknowledgement is quoted).
• Fix a pre-existing YAML indentation bug in the docs snippet - automation_sigen_ess_max_charging_limit_input_number_action was nested two spaces too deep, making it a child of the first automation's actions instead of a sibling automation. Caught by parsing the snippet directly with PyYAML.

A more advanced variant - ratcheting the target up only in response to confirmed solar surplus over each period (comparing PV/load totals as the trigger, rather than using the SoC reading itself to decide, so it's immune to sensor noise entirely) is being tested live but deliberately not included here - docs should stay simple and proven, not experimental.

Test plan

• ./run_pre_commit (via coverage/run_pre_commit) - all hooks pass
• Full automation YAML snippet parses correctly with PyYAML (3 top-level automations, correctly structured)
• sensor.sigen_plant_battery_state_of_charge confirmed to exist and report correctly on live hardware
• Core fix (pinning discharge_cut_off_state_of_charge to current SoC) live-tested on real Sigenergy hardware, root cause confirmed via controlled testing - see Sigenergy: Freeze Charging template still forces grid-import at full price (discharge cutoff=100 in Maximum Self Consumption) — related to #2872 #4375
• Live-observed tonight during a real Freeze Charging window: SoC held steady (not climbing toward a stale target) while grid import correctly tracked only real house load - matches expected behaviour, contrasts with the pre-fix bug
• Docs-only change, no code touched

Closes #4375