Rename cooktop.py capabilities module to range.py to avoid PR #23 collision

PR #23 independently adds registry/capabilities/cooktop.py for an unrelated
standalone-cooktop product (NA9300K-class, burner state encoded in
/mode/vs/0's options array) -- different hardware and a different OCF
surface than issue #44's oven+cooktop combo range, but the same file path.
Rename ours to range.py to keep both mergeable.

custom_components/localthings/registry/by_type/range.py

@@ -5,7 +5,8 @@ connected capabilities wholesale (a range's oven half is the same OCF
 surface as a standalone oven) and adds the cooktop-specific capabilities
 for the burner half.
 """
-from ..capabilities import common, cooktop, ignored, oven
+from ..capabilities import common, ignored, oven
+from ..capabilities import range as range_caps
 from ._base import DeviceRegistry, _build
 
 REGISTRY = DeviceRegistry(
@@ -21,8 +22,8 @@ REGISTRY = DeviceRegistry(
         oven.OVEN_DOOR,
         oven.OVEN_CONNECTED,
         oven.OVEN_SPEC,
-        cooktop.COOKTOP_STATUS,
-        cooktop.COOKTOP_SPEC,
-        cooktop.COOKTOP_SAFETY,
+        range_caps.COOKTOP_STATUS,
+        range_caps.COOKTOP_SPEC,
+        range_caps.COOKTOP_SAFETY,
     ]),
 )

custom_components/localthings/registry/capabilities/range.py

@@ -1,6 +1,12 @@
 """Capabilities for the cooktop half of range/combo appliances (issue #44,
 model TP1X_DA-KS-RANGE-0102X).
 
+Not to be confused with PR #23's registry/capabilities/cooktop.py, which
+covers an unrelated standalone-cooktop product (NA9300K-class) that encodes
+burner state as strings inside /mode/vs/0's options array instead of the
+structured /cooktop/status/vs/0 resource this module reads -- two different
+OCF surfaces that happen to share the English word "cooktop".
+
 Unlike the rest of the OCF surface, these hrefs use plain camelCase field
 names (no `x.com.samsung.da.` prefix) -- `/cooktop/status/vs/0` already
 looks like a vendor resource migrated onto OCF-standard-shaped field naming.