Add min_time and max_time timestamps to recorder.get_statistics

[ciux23]

Describe your core improvement

Add support for returning min_time and max_time timestamps in recorder.get_statistics, enabling users to see exactly when minimum and maximum values occurred during the statistical period.

Current limitations

The current recorder.get_statistics implementation only returns numerical min and max values without their corresponding timestamps. This creates significant limitations for users who need temporal context with their statistics.

Missing temporal context: Users cannot determine when peak values occurred (e.g., whether highest temperature was at noon or midnight)
Inefficient workarounds: Users must write complex SQL queries or fetch full history data to get this information
Limited dashboard utility: Statistics displayed in dashboards lack actionable time information
Reduced automation potential: Automations cannot leverage time-based patterns from statistical data

Example enhanced response:

{
  "min": 18.5,
  "max": 24.8,
  "min_time": "2024-07-03T06:15:00Z",
  "max_time": "2024-07-03T14:30:00Z"
}

Technical benefits

✅ Non-breaking change — Existing integrations continue working unchanged
✅ Zero performance impact — Data already exists in statistics table
✅ Database-efficient — Leverages existing timestamp field without additional queries
✅ Industry standard — Aligns with how InfluxDB, Prometheus, and other platforms work
✅ Backward compatible — New fields are optional additions

Additional context

Example use cases:

• 🌡️ HVAC optimization: Know when daily temperature peaks occur to optimize heating/cooling schedules
• 🔆 Solar analysis: Identify exact peak production times for battery charging strategies
• 💡 Energy monitoring: Pinpoint when consumption spikes happen for load management
• 🏠 Home automation: Create time-aware automations based on historical patterns

Technical justification:
The required data is already available in the statistics table via the timestamp field. Implementation would involve modifying the aggregation logic in recorder.get_statistics to include these timestamps.

Alternatives considered:
Separate API endpoint would fragment the statistics API unnecessarily. SQL queries are the current workaround but are complex and fragile for average users. Full history retrieval is inefficient and resource-intensive for large datasets.