Apply issue #56 field reports: filter direction, drop Blooming_*

Incorporates confirmed answers from the issue thread:
- FilterProgress counts down as the filter wears (100 = fresh), so the
  sensor is renamed filter_progress -> filter_life to match the direction
  instead of implying "usage" like the AC/range_hood filterUsage sensors.
- Blooming_* has no corresponding SmartThings app setting, so it's dropped
  entirely rather than kept as an unexplained diagnostic.
- OptionCode_60282 and the missing humidity sensor are confirmed correct
  as already modeled (not user-facing / genuinely absent on this model).

Five running-state diagnostics dumps (Auto/Sleep/Low/Medium/High) rule out
the original guess that Comode_* is the fan-speed selector -- it reads
'Off' on every one of them. /airflow's speed field doesn't map monotonically
to the five settings either (0 for both Auto and High, 3 for Low/Medium/
Sleep), and all five dumps were captured within about three minutes of each
other -- one poll cycle at this integration's 30s summary interval -- so
fan-speed modeling stays unbuilt pending a cleaner capture.

tests/fixtures/golden/air_purifier.json

@@ -1,7 +1,6 @@
 {
   "state_keys": [
     "alarm_code",
-    "blooming_level",
     "clean_level",
     "device_active",
     "diagnosis_status",
@@ -13,7 +12,7 @@
     "energy_this_month_kwh",
     "fan_direction",
     "fan_speed_level",
-    "filter_progress",
+    "filter_life",
     "fine_dust",
     "odor",
     "operating_mode",