fix(subdevices): don't materialize a slot whose only live state is a meter

Issue #214: a single-split ARTIK051_KRAC_18K showed up in HA as two air
conditioners. Its /device/1 answers the same unused-slot shape the Pattern A
reporter's /device/2 does -- every operational rep empty {} -- but also
reports a populated /energy/consumption/vs/1. Running discovery against the
reporter's own quoted subdevice block reproduces their diagnostics exactly
(21 bound entities, the same six hrefs), and of those 21 the only primary
entity with a non-None value is energy_kwh: a lifetime kWh total was the
sole thing passing discover_partitioned's liveness gate and materializing
the phantom.

A single-split AC has one compressor and one energy meter, so a
whole-appliance running total appearing under a second index is the
appliance's own bookkeeping, not evidence that hardware is installed at that
slot. Exclude cumulative meters (HA's total/total_increasing state classes,
plus the energy/water/gas device classes for the descriptors that
deliberately declare no state class) from the gate. The gate never applies
to MAIN, and across the whole fixture corpus every device has at least one
non-meter live primary, so no existing device's entities change -- verified
by the golden for the new fixture being identical to the plain KRAC one.

Also implement async_remove_config_entry_device. A subdevice's HA device
outlives the discovery that created it, so a phantom materialized by an
earlier release stays in the registry with no way to delete it from the UI
-- which is the state the second reporter on that issue is in, with a
refrigerator whose diagnostics now report no subdevices at all. Devices the
entry currently provides still refuse removal. No automatic pruning:
enumeration is one-shot and a real sibling can miss a poll (issue #205 on
the reference hardware), so auto-removal would discard a live subdevice's
name, area and automations on a transient miss.

The new fixture's /device/1 seed is the reporter's verbatim capture; its
master half comes from the corpus's other KRAC unit, with the deviations
spelled out in seeds_note.

Claude-Session: https://claude.ai/code/session_01HzUMLnSWBT64o4BQkVEzXp

.claude/skills/adding-device-support/SKILL.md

@@ -403,11 +403,16 @@ the dump in this order; each step rules out a different cause.
    for that sibling.
 3. **`subdevices_skipped`** — did we find it and reject it? A candidate lands
    here when its seed(s) answered but it produced no *primary*
-   (non-diagnostic) entity with a populated value. Its `resources` block
-   holds the exact reps the gate judged, so you can check the call
-   yourself. If every power/mode/temperature rep is `{}`, the subdevice is
-   an unused slot and the skip is correct. If they're populated, the gate
-   is wrong — that's a bug worth a fixture. A flat-fallback candidate whose
+   (non-diagnostic), non-meter entity with a populated value. Its
+   `resources` block holds the exact reps the gate judged, so you can check
+   the call yourself. If every power/mode/temperature rep is `{}`, the
+   subdevice is an unused slot and the skip is correct — a populated
+   `/energy/consumption/vs/<n>` alongside them doesn't change that (issue
+   #214: an appliance's lifetime kWh counter shows up under an unused
+   slot's index too, and materializing on it produced a phantom duplicate
+   air conditioner, so cumulative meters are excluded from the gate). If
+   the *operational* reps are populated, the gate is wrong — that's a bug
+   worth a fixture. A flat-fallback candidate whose
    only confirmed href is `/information/vs/0` (never bound to any entity —
    only ever read for device-type resolution) will *always* land here until
    more of its hrefs are confirmed live; that's the gate working as
@@ -430,7 +435,27 @@ the dump in this order; each step rules out a different cause.
 Two things that are *not* the fix: adding a capability for an indexed href
 (see §8), and loosening the liveness gate to "any populated entity" — a
 rejected slot routinely reports a non-`None` *diagnostic* value off an empty
-resource, which is exactly what the primary-entity filter exists to ignore.
+resource (and, on some boards, a populated appliance-level meter), which is
+exactly what the primary-entity and meter filters exist to ignore.
+
+### The mirror image: "I have one subdevice too many"
+
+Same dump, read the other way (issue #214). A duplicate device in HA is
+either a candidate that shouldn't have materialized — check `subdevices`
+for one whose `resources` are all `{}` except a meter/`/information`, which
+is the unused-slot shape from step 3 — or a **leftover registry entry** from
+a release that did materialize it. Those two look identical in the HA UI and
+are told apart by the dump: a leftover shows `subdevices: []` (or no entry
+for that key) while the device is still listed in HA.
+
+Nothing prunes a leftover automatically — subdevice enumeration is one-shot
+and a real sibling can miss a poll, so auto-removal would throw away a live
+subdevice's name/area/automations on a transient miss. The integration
+implements `async_remove_config_entry_device`
+(`custom_components/localthings/__init__.py`) instead, which is what puts a
+working "Delete device" button on anything this entry no longer provides;
+devices it *does* provide refuse removal, since HA would just recreate them.
+Tell the reporter to delete the stale device, don't add a pruning pass.
 
 ## Key files
 - `registry/subdevices.py` — `Subdevice`, enumeration, canonical ⇄ actual href