feat(airconditioner): reset the legacy filter counter locally

FilterCleanAlarm_Clear, through the same single-token options merge as every
other setting on /mode/vs/0. Measured on an ARTIK051_KRAC_18K: 2.04 Changed and
FilterTime_95 (9 h 30 min) -> FilterTime_0, still zero on a fresh DTLS session
and on every poll after; none of the other 17 tokens moved and the alarm
entries stayed Deleted.

The counter has had no reset until now, and the descriptor said so: two earlier
rounds against live hardware failed, and the conclusion drawn from them was
that the reset had to be cloud-only. That conclusion was wrong, and the way it
was reached is the interesting part -- it came from diffing every resource the
appliance reports before and after pressing reset in Samsung's app, which
showed only the counter zeroing and the alarm clearing. A trigger token cannot
show up in such a diff, because a trigger is never stored. The appliance's own
app sends this token and skips the write when the counter is already zero.

Both failures stay in the comment, because they say what this is not: writing
FilterTime_0 (the value is not writable -- 5595 -> 5595 after 69 s, 1925 ->
1925 after 65 s, two units, opposite power states), and POSTing the cloud
capability's command name to /actions/vs/0 (real name, wrong transport).

Gated on the FilterTime_ token, so it appears only where there is a counter to
reset; newer boards report filter usage through their own resource and would
need a different mechanism.

custom_components/localthings/registry/capabilities/airconditioner.py

@@ -555,9 +555,9 @@ CLIMATE = Capability(
         ),
         # Filter time in tenths of an hour, counting UP since last filter
         # reset; scale and direction confirmed against the Samsung app and
-        # the /alarms/vs/0 threshold crossing (500h). No reset entity: no
-        # local write path has been found -- see
-        # docs/investigations/ac-filter-reset.md for what's been tried.
+        # the /alarms/vs/0 threshold crossing (500h). Resettable via the
+        # FilterCleanAlarm_Clear trigger token below -- see
+        # docs/investigations/ac-filter-reset.md for how that was found.
         SensorDesc(
             key="filter_time",
             rep_fn=_option_token_num("FilterTime", divisor=10),
@@ -567,6 +567,26 @@ CLIMATE = Capability(
             state_class="measurement",
             icon="mdi:air-filter",
         ),
+        # Resets the counter above via the FilterCleanAlarm_Clear token, the
+        # same single-token options merge as every other /mode/vs/0 setting.
+        # It's a trigger, not a stored setting -- the board zeroes the
+        # counter on receipt and never reports this token back, which is why
+        # it doesn't show up in exists_fn like the others. Confirmed on an
+        # ARTIK051_KRAC_18K: FilterTime_95 -> FilterTime_0, stable across a
+        # fresh DTLS session and every poll after (see the investigation doc
+        # for why this was believed cloud-only until now).
+        ButtonDesc(
+            key="filter_time_reset",
+            field="",
+            payload="FilterCleanAlarm_Clear",
+            icon="mdi:restart",
+            entity_category="config",
+            exists_fn=_has_option_token("FilterTime"),
+            write_fn=lambda p, rep, href=None: (
+                ["mode", "vs", "0"],
+                {"x.com.samsung.da.options": [p]},
+            ),
+        ),
         # FilterTime_'s threshold, exposed as a static 4-way radio
         # (180/300/500/700h, matching the app) since options[] tokens carry
         # no supported-values list to read from, unlike air_filter_threshold

custom_components/localthings/translations/en.json

@@ -120,6 +120,9 @@
       "auto_clean_stop": {
         "name": "Stop auto clean"
       },
+      "filter_time_reset": {
+        "name": "Reset filter time"
+      },
       "pause": {
         "name": "Pause"
       },