v1.0.16

Fixed

• Work-mode and data-freshness sensors now expose valid states to HA's automation editor. sensor.foxess_work_mode (German: sensor.foxess_betriebsmodus) and sensor.foxess_data_freshness previously had no device_class and no options attribute, so when a user picked either entity for an automation state-trigger or condition, HA's editor fell back to a free-text input instead of a valid-state dropdown. Both sensors now declare device_class: enum and an options list — work mode lists the five WorkMode values (SelfUse, ForceCharge, ForceDischarge, Backup, Feedin) sourced directly from the WorkMode enum (so any future enum addition propagates automatically), and data-freshness lists the three valid sources (ws, api, modbus). Twelve-test regression suite in tests/test_sensor.py (TestWorkModeSensorOptionsCoverage, TestDataFreshnessSensorOptionsCoverage, TestNonEnumSensorsRetainFreeFormState) parametrises over every value native_value can return for each sensor and asserts it is in _attr_options, plus a structural test that proves the work-mode list is sourced from the canonical enum (not hard-coded), plus a negative-guard test that prevents future blanket-enum refactors from accidentally enumerating free-form display sensors (status, charge-window, time-remaining). Resolves a user-reported automation-authoring papercut. This is the second instance of the "enum sensor missing options" pattern (first: 2026-04-25 SmartOperations freeze in 1.0.12); flagged in docs/knowledge/META.md as a watching pattern — a third instance would graduate it to a constraint.