RFC: ML energy consumption predictor

[pookey]

Summary

This adds an optional ML module for predicting 24h energy consumption at 15-minute resolution using XGBoost. It integrates with the battery optimizer via a new consumption_strategy config setting.

Important caveats — please read before reviewing:

• This is an RFC / experimental feature, not necessarily something that belongs in core. In my testing so far, the ML predictions are actually worse than a simple weekly average profile (influxdb_profile strategy). The model needs significant training data and tuning to outperform naive baselines.
• Startup time impact: The ML module adds ~10-15s to boot (model training + prediction generation). This is acceptable for my use case but may not be for all users.
• Docker image size: xgboost + scikit-learn add ~100MB+ to the image. The base image also switches from Alpine to Debian (required for prebuilt xgboost wheels).
• The ml config section is fully optional — if omitted, the system behaves exactly as before with zero overhead.

I'm happy to discuss whether this should live in core, be a separate add-on, or be structured differently. Opening this PR mainly to share the work and get your thoughts on the approach.

What's included

• ml/ module (6 files, ~2500 lines): Standalone XGBoost predictor with CLI (train, predict, evaluate, report)
• 4 consumption strategies: sensor (default, unchanged), fixed, influxdb_profile (7-day weekly average from InfluxDB), ml_prediction
• ML Report tab: Frontend dashboard showing model metrics, feature importance, forecast vs baselines
• /api/ml-report endpoint: Model status, predictions, and comparison data
• Config: New ml section in config.yaml (location, feature sensors, training params)
• Daily retrain: Cron job at 23:00, predictions cached with date-based invalidation
• Infrastructure: InfluxDB batch power sensor fetching, historical data persistence, sensor gap-filling

Changes from previous PR #23

All 9 review items from @johanzander's feedback on #23 have been addressed:

• ✅ No hardcoded sensor IDs — config moved to config.yaml ml section with placeholder values
• ✅ Timezone from config (ml.location.timezone), not hardcoded
• ✅ Coordinates match timezone (configurable)
• ✅ consumption_strategy loaded in from_ha_config() with direct dict access (no silent fallback)
• ✅ No .get() with fallback defaults for required settings — fails loudly if missing
• ✅ consumptionStrategy field has no default in APIBatterySettings
• ✅ ML packages in shared requirements.txt (needed at runtime for strategy dispatch)
• ✅ Logging doesn't trigger heavy queries — uses cached predictions
• ✅ No duplicate CHANGELOG sections (CHANGELOG not modified in this PR)

What's NOT included (intentionally excluded)

• Chart fixes (EnergyFlowChart, BatteryLevelChart)
• Locale/currency cleanup
• Test refactoring
• Docs restructuring
• Schedule verification / deployment failure tracking

Test plan

• ml report command completes and generates HTML dashboard
• Feature flags properly exclude features when disabled
• System boots and optimizes normally with consumption_strategy: "sensor" (no ML overhead)
• System boots with consumption_strategy: "ml_prediction" and uses ML forecasts
• influxdb_profile strategy produces reasonable weekly average profiles
• ML Report tab renders in frontend
• Verify with fresh install (no existing model artifacts)

[pookey]

Superseded by #33 (consumption strategies) and #34 (ML predictor). Split into two focused PRs for easier review.