fix: surface HA request error bodies + dedupe Growatt charge-rate writes (#741)

[pra]

Summary

• Surface the HTTP response body in ha_api_controller's request-failure logs, so an opaque 500 from an HA service call is diagnosable from the log.
• Dedupe the Growatt charge-power-rate register write (adjust_charging_power, power-monitor-off path) — the last un-deduped per-tick write after fix: dedupe redundant grid_charge/discharge_rate writes on Growatt cloud #402 and fix: defer Growatt MIN TOU writes until a segment is about to take effect #568 — so an unchanged rate isn't re-sent to the cloud each cycle.

Together these address #741 (surface the body + reduce write churn).

What we observed (and what we don't claim)

On a Growatt Open API V1 (cloud / growatt_server) install, control writes intermittently fail with growattServer.exceptions.GrowattV1ApiError: Error during writing parameter (ac_charge / charge_power / time segment). The API returns a generic error — no explicit rate-limit or quota message — so the exact cause is unconfirmed. The failure pattern (rejections cluster later in active periods, then recover) is consistent with a write-rate/quota limit, but we're not asserting that as fact.

What we can say empirically: after #402 (grid_charge/discharge_rate dedup) and #568 (TOU write deferral), the charge-rate register was still re-sent every scheduler tick from adjust_charging_power's direct-write path (power monitor disabled), because it bypasses _write_period_to_hardware's dedup. Cutting those surplus writes coincided with fewer rejections in a multi-day before/after (below). This is a likely contributor to the failures — the same framing #402 used ("a likely contributor to GrowattV1ApiError").

The failure was also hard to diagnose: _api_request logged only str(e) ("500 Server Error … for url …"), discarding response.text.

Fix

• ha_api_controller._describe_request_error() — str(e) plus response.text when present; used in the retry and final-failure logs. No behaviour change beyond logging; timeouts/connection errors (no response body) are unaffected. In field use it surfaced, e.g., a startup-timing {"result":"error","message":"System is not ready with state: setup"} that the old format hid; for the Growatt/Nordpool cloud errors it (correctly) shows the body is a generic 500, pointing to integration-level debug.
• InverterController.write_charge_rate_if_changed() — mirrors the existing _last_written_* / dedupe_register_writes pattern; skips a charge-rate write when the value is unchanged, leaves _last_written unset on a failed write so the next tick retries. adjust_charging_power's direct-write path routes through it. SolaxModbusGrowatt TOU (dedupe_register_writes = False) still writes unconditionally, unchanged.

Control/apply layer only — no optimizer, intent, or DP change.

Test plan

• write_charge_rate_if_changed: RED→GREEN unit tests — unchanged rate skips the write, changed rate writes, failed write retries next call.

• _describe_request_error: body appended when present, plain str(e) when absent/timeout.

• core/bess fast suite 1672 passed, slow suite 564 passed, 0 failures. (backend/tests bot-pipeline failures on the dev machine were a missing-jq env gap, unrelated.)

• Live before/after on a real Growatt-cloud install (small sample, absolute counts — not a rigorous failure-rate %):

  	before (no charge-rate dedup)	after (with dedup)
  charge_power write rejections	~6 in one afternoon	Sep 7: 4, Sep 8: 0, Sep 9: 4, Sep 10: 0
  dropped writes (retries exhausted)	0	0 over 3 days

  Reading: a reduction, not elimination — rejections still occur in clusters on active evenings (likely legitimate per-period rate changes the dedup can't remove, plus other writes). No charge/discharge window was dropped. Not proof of a quota, and the sample is small.

Addresses #741.

[bess-agent]

Reviewed the diff: well-scoped, follows the existing _last_written_* / dedupe_register_writes dedup pattern (#402), RED→GREEN unit tests added, CHANGELOG updated, no optimizer/intent/DP changes. No correctness issues found — set_charging_power_rate has a single production writer on this path (power_monitor.py:268 is mutually exclusive by power_monitoring_enabled), so the new cache stays coherent, and a failed write leaves _last_written_charge_rate unset for retry.

Minor (non-blocking): the _last_written_* block comment in inverter_controller.py still says these are written by _write_period_to_hardware, which no longer holds for _last_written_charge_rate.

This will be approved once the live Growatt-cloud observation box in the description is checked and CI is green.