docs(alphaess): state that the Open API cannot control export

[springfall2008]

Documentation-only. Related to #4701 and #4723 — deliberately not auto-closing either, since a follow-up code change is still on the table (see Follow-ups).

Summary

The AlphaESS Open API has no forced-export, working-mode or dispatch endpoint, and AlphaESS's own documentation describes ctrDis as a discharge permission window — self-consumption inside it, charge-only outside it — rather than a forced export. So:

• Force Export does nothing. A programmed export window has the battery cover house load and export nothing beyond genuine solar surplus, which is what @dragon2611 observed in ALPHAESS: Time based dischage does not force discharge #4701.
• Freeze Export does nothing either. Predbat implements it by disabling charging and leaving the inverter in Demand mode. Nothing in the API stops the battery charging from solar — gridCharge gates only timed grid charging — so the payload built for Freeze Export comes out identical to the Demand mode one.
• Programming the window has a cost. execute.py pre-arms the discharge window up to plan_interval_minutes ahead of each planned export slot, which on the permission-window semantics bars the battery from covering house load until that window opens. That is the side effect reported independently in ALPHAESS: Set discharge timeslot when exiting Axle VPP status. #4723.

The docs now say so plainly and recommend select.predbat_mode = Control charge on AlphaESS, which stops export windows being planned or written at all. Forced export is available on the same hardware over local Modbus (dispatch registers), just not over the cloud API — noted as the route for anyone who needs it.

Two existing claims are corrected as part of this:

• apps-yaml.md said a zero rate is how Predbat signals "freeze charge or freeze export". The zero rate only holds the battery out of discharging; it cannot stop it charging.
• The inverter_freeze_export_discharge_rate note cites an AlphaESS observation. That cannot have come from the cloud component, which cannot disable charging at all, so the note now says it does not apply here.

Design-spec field-verification item 3 ("whether surplus above house load reaches the grid during a discharge window") is marked ANSWERED, No; item 2 gains the manual's supporting wording, and its incorrect claim that freeze export depends on it is corrected to freeze charge and the iBoost/car holds.

Files: docs/apps-yaml.md, docs/inverter-setup.md, docs/components.md, the alphaess.py module docstring, and the design spec.

Testing

No behaviour change — the payload builders are correct for what the API accepts and are left intact, so there is no new code to test.

• cd coverage && ./run_pre_commit — all hooks pass (markdownlint, cspell, ruff, black), and the quick suite passes with 4 slow tests skipped.
• tools/triage_test.sh alphaess_control — PASSED. All six alphaess_* test modules also pass unchanged.

Follow-ups (not in this PR)

1. Nothing enforces the recommendation — a user left in Control charge & discharge still gets a plan built on exports that never happen, plus the pre-arm write from ALPHAESS: Set discharge timeslot when exiting Axle VPP status. #4723. automatic_config could set this for AlphaESS systems, with a log line.
2. A unit test pinning "the Freeze Export payload equals the Demand mode payload" would turn this limitation into an executable regression guard.
3. batHighCap is the one untested lever: if it is a global charge ceiling rather than only the in-window target, writing it at the current SoC would stop solar charging and give real Freeze Export behaviour. Worth a field test before anything is built on it.