feat: accept an external consumption forecast as a time-series entity

[johanzander]

Summary

• Adds ha_consumption_series: a new consumption-forecast strategy reading a user-authored HA time-series entity (raw_today/raw_tomorrow attributes of timestamped {start, value} records), mirroring the existing price-manager entity pattern rather than solar's hour-indexed parser (which can't represent sub-hourly data).
• BESS still does not model loads itself — no EV/weather/occupancy modelling was added. The user's own HA template or automation builds the shaped series; BESS only normalizes 15- or 60-minute record spacing onto the DP's quarter-hour grid.
• A missing, stale, malformed, or horizon-short series raises an explicit ConsumptionForecastUnavailableError — this strategy never silently falls back to a flat profile, unlike ha_statistics's fixed-value fallback on insufficient data.
• Renames the scalar sensor strategy's misleading "Consumption Forecast" UI category to "Consumption Average (48h Rolling)" (it was never a real forecast) and adds a new "Consumption Forecast Series" category for the new entity.
• Adds an example HA template (baseline + a scheduled EV block) to docs/USER_GUIDE.md so the seam is usable without starting from a blank YAML file.

Root cause

From the issue: every existing consumption strategy is either a constant or an in-house statistical model. ha_statistics's trimmed mean deliberately discounts one-off spikes (the right call for outlier robustness) but as a side effect is permanently blind to a known, predictable load like an EV session — nothing puts that load back into the forecast. Solar has an external-forecast seam (Solcast); consumption had none.

Fix

• HomeAssistantAPIController.get_consumption_forecast_series() / get_consumption_forecast_series_tomorrow() (core/bess/ha_api_controller.py) — fetch and normalize the entity, mirroring price_manager.py's raw_today/raw_tomorrow parsing.
• BatterySystemManager._get_consumption_forecast dispatches to it for the new strategy; _extend_consumption_predictions (extracted from the existing tomorrow-horizon-extension logic) uses the entity's real raw_tomorrow data instead of repeating today's pattern when the DP horizon spans midnight — the same treatment solar's _fetch_tomorrow_solar_forecast already gets.
• Health-check coverage (sensor_collector.check_prediction_health) and the strategy-comparison endpoint (get_consumption_forecast_comparison) both cover the new strategy.
• Frontend: new radio option + description in HomeFormSection.tsx, sensor category rename + addition in sensorDefinitions.ts, updated SensorConfigSection.tsx detection logic, ConsumptionForecastComparison.tsx chart labels/colors.

Test plan

• ./scripts/quality-check.sh passes locally (fast suite: 1399 passed, 15 skipped; frontend: 103 passed; Black/Ruff/TypeScript/ESLint clean)
• .venv/bin/pytest -m slow passes (394 passed, 3 skipped)
• New unit tests: entity parsing (happy path, hourly upsampling, stale/malformed/short-horizon/unsupported-interval failure modes), strategy dispatch + no-silent-fallback, health-check integration, and an end-to-end test that runs a shaped EV-load series through the real DP optimizer and confirms it produces a different (correct) plan than a flat series
• Local E2E verification via docker-compose.ci.yml (real backend + mock-HA): configured the new strategy and a shaped entity via the real PATCH /api/settings API, confirmed GET /api/consumption-forecast-comparison returns the correct shaped hourly profile (EV hour at 16.0 kWh vs 1.2 kWh baseline) through the live system, confirmed the health check reports OK with the exact shaped series and then a clear ERROR (no silent fallback) when the entity's raw_today data was removed, and confirmed the new frontend strings are present in the actual served JS bundle

Closes #428

[johanzander]

Still conflicted — merge attempted twice today, both aborted

This PR is CONFLICTING against main and has been since ~2026-08-02. Two attempts today, neither landed:

1. A manual sweep-prs pass merged origin/main and hit semantic conflicts in 5 files, so it aborted per that skill's rule against resolving someone else's logic conflicts. Tree left clean.
2. A background session (pr437-conflicts) was dispatched to resolve them and produced nothing — HEAD still 0a6e91f4, 3 commits ahead, no MERGE_HEAD, no tracked file written in 2.5 hours. Stopped. Nothing lost, nothing done.

The conflicts

git merge origin/main conflicts in:

• core/bess/ha_api_controller.py
• core/bess/sensor_collector.py
• core/bess/settings_store.py
• core/bess/tests/unit/test_prediction_health_check.py
• frontend/src/components/settings/HomeFormSection.tsx

These are logic conflicts, not mechanical ones. Resolving them means preserving both this branch's external-consumption-forecast feature and ~2 weeks of main drift in the same files — per docs/agents/rules.md, with no silent fallbacks or defensive error handling added while reconciling.

One trap worth knowing before you start

The worktree accumulated 150 untracked files byte-identical to origin/main, which blocked the merge with The following untracked working tree files would be overwritten by merge before any conflict was even reported. Git truncates that list at ~4KB, so it cannot be enumerated from the error message — derive it instead:

comm -12 <(git ls-files --others --exclude-standard | sort) \
         <(git ls-tree -r origin/main --name-only | sort)

Then delete only the entries that are byte-identical to origin/main (verify with git show origin/main:$f | cmp -s - "$f"); the merge restores them. That has already been done once, so it may not recur — but check, because it presents as an unrelated failure.

[bess-product-owner]

Parked: not to be merged yet — awaiting user feedback

Maintainer decision, recorded here so it stops being re-derived every backlog pass. Board fields set to match:

• Priority: P4
• Awaiting: reporter

Together those suppress this PR from the rhythm pass's action list. It is still counted and listed as deferred, so it stays findable — it is parked, not dropped.

Do not resolve the conflicts yet. This PR has been CONFLICTING since ~2026-08-02 with semantic conflicts in five files:

• core/bess/ha_api_controller.py
• core/bess/sensor_collector.py
• core/bess/settings_store.py
• core/bess/tests/unit/test_prediction_health_check.py
• frontend/src/components/settings/HomeFormSection.tsx

Two attempts have already been spent on them — a sweep-prs pass that correctly aborted rather than resolve someone else's logic conflicts, and a background session that wrote nothing in 2.5 hours. A third attempt would cost the same and land in the same place, because the blocker is not the merge: the feature's shape needs user feedback first, and resolving conflicts against a design that may still change is wasted work.

Unpark by clearing Awaiting once that feedback is in.