SF1000 / Twin brightness history is recorded but unreadable through /history

record_hub_chart_history writes (‘hub’,’sf1000_brightness’) and (‘hub’,’twin_sf1000_brightness’) on every poll, but neither metric name is in HUB_VALUE_KEYS. So resolve_entity_metric(‘sensor.dsc_hub_sf1000_brightness’) falls past the sensor.dsc_hub branch into the catch-all and resolves to (COMPUTED_SEAT, ‘sensor.dsc_hub_sf1000_brightness’) – a series nothing ever writes. GET /history for that entity answers tracked: true, recorded: false, points: [] while the real rows sit under the hub seat, unreachable because no entity_id maps to them. Consequence: there is no way to chart or replay the sunrise/sunset ramp. Hit directly on 2026-09-12 while trying to reconstruct a reported late lights-on – the one series that would have settled it was the one that could not be read. Fix: add sf1000_brightness and twin_sf1000_brightness to HUB_VALUE_KEYS (the on/off twins are already hand-mapped in ENTITY_METRIC_MAP). Note this is the same ‘tracked true, zero rows’ trap is_recorded was written for.