fix: MQTT forecast topics were 4x too low at 15-min resolution

[MaStr]

Summary

• /FCST/production, /FCST/consumption and /FCST/net_consumption are documented as being in W, but published the raw Wh-per-interval array unchanged. That's numerically identical to average power at 60-minute resolution, but only 1/4 of it at 15-minute resolution — so 15-min forecasts looked 4x too low to anything reading the topic as Watts (e.g. comparing against Solcast's own portal).
• value now stays consistently Wh per interval regardless of time_resolution_minutes, and each entry additionally carries a power_w field (average power in W), so both an energy- and a power-oriented consumer get an unambiguous number.
• /FCST/prices is unaffected (no power_w, doesn't apply).
• Updated the module docstring and docs/integrations/mqtt-api.md (topic list + example payload) to match.
• config/telegraf.sample.conf needs no change: its json_v2 parser auto-detects all keys in each data object (only time_end is excluded), so power_w is picked up automatically; the pivot processor only touches the value field, leaving power_w as its own field.

Test plan

• ./run_tests.sh — 799 passed
• uv run pylint src/batcontrol/mqtt_api.py — 9.57/10 (no new warnings)
• New regression tests in tests/batcontrol/test_mqtt_api.py::TestForecastPublishing cover: value stays raw Wh at 15 and 60 min, power_w scales correctly (4x at 15 min, 1x at 60 min), and prices never gets a power_w field.
• Verified against a live system's debug log + a standalone repro script that the underlying Solcast 30->15min interpolation itself was already correct; the bug was isolated to the MQTT publish layer.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes a unit mismatch in MQTT forecast topics at 15-minute resolution by keeping forecast value as Wh-per-interval (independent of interval length) and adding an explicit power_w (average Watts) field for energy-based forecasts, aligning both implementation and published API expectations.

Changes:

• Update /FCST/production, /FCST/consumption, and /FCST/net_consumption publishing to keep value as Wh per interval and add power_w (average W).
• Add _energy_to_power() and extend _create_forecast(..., include_power=True) to optionally include power_w.
• Add regression tests for 15-min vs 60-min behavior and update MQTT API documentation/examples accordingly.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/batcontrol/mqtt_api.py	Changes forecast publishing semantics and payload structure (value in Wh/interval + optional power_w).
tests/batcontrol/test_mqtt_api.py	Adds regression tests ensuring correct scaling and that prices remain unchanged (no power_w).
docs/integrations/mqtt-api.md	Updates MQTT topic docs and example payload for the new forecast payload format.

Comments suppressed due to low confidence (1)

docs/integrations/mqtt-api.md:233

• This section also references general.time_resolution_minutes, but the setting is time_resolution_minutes at the top level of the config. Align the docs with the actual config key name.

- `time_end` - Unix timestamp for end of the interval (15 or 60 minutes later,
  depending on `general.time_resolution_minutes`)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

docs/integrations/mqtt-api.md:225

• In the JSON example, the second entry's time_end is off by 1 second. _create_forecast() sets time_end to time_start + interval_seconds (e.g., 900s for 15-min), so 1696436100 should end at 1696437000, not 1696436999.

    {
      "time_start": 1696436100,
      "value": 800.0,
      "power_w": 3200.0,
      "time_end": 1696436999
    }

docs/integrations/mqtt-api.md:234

• This section references general.time_resolution_minutes, but the config key is time_resolution_minutes at the top level (and the same page already uses time_resolution_minutes above). Keeping the key consistent avoids confusing users.

- `time_start` - Unix timestamp for start of the interval
- `time_end` - Unix timestamp for end of the interval (15 or 60 minutes later,
  depending on `general.time_resolution_minutes`)
- `value` - Forecasted value for that interval: Wh for production/consumption/net_consumption,