Drop the per-entry provenance comments on _OIC_TYPE_TO_KEY

The "issue #N" / "OCF spec" trailing comments and the header paragraph
explaining them added noise without adding anything the value side of
the table (a real _REGISTRY_BY_KEY key) doesn't already guarantee. Update
the skill's guidance to match.

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

@@ -197,16 +197,15 @@ outcomes:
   keeps `_BOARD_TOKEN_TO_KEY` current:
 
 ```python
-'oic.d.dishwasher': 'dishwasher',             # OCF spec
-'x.com.st.d.steamcloset': 'air_dresser',      # AirDresser / steam-closet garment care
+'oic.d.dishwasher': 'dishwasher',
+'x.com.st.d.steamcloset': 'air_dresser',
 ```
 
-- **Mark provenance in a trailing comment.** `# issue #N` for a string seen
-  verbatim in a real dump; `# OCF spec` for one not seen yet but defined by
-  the OCF Smart Home Device Specification's Table 9-1 with the exact same
-  `oic.d.<category>` shape as an already-confirmed entry — that shape is
-  low-risk to add ahead of a dump because, unlike a board-token entry, there's
-  no tokenizing or delimiter-spelling judgment call involved.
+- A string not yet seen in a dump is still fine to add on the strength of the
+  OCF Smart Home Device Specification's Table 9-1 alone, as long as it has the
+  exact same `oic.d.<category>` shape as an already-confirmed entry — that
+  shape is low-risk ahead of a dump because, unlike a board-token entry,
+  there's no tokenizing or delimiter-spelling judgment call involved.
 - **Only add a row once there's a real registry key on the right** (a key in
   `_REGISTRY_BY_KEY`). A type naming a product this integration has no
   registry for stays unmapped rather than getting coerced onto the

custom_components/localthings/registry/by_type/__init__.py

@@ -193,16 +193,6 @@ def _consumer_model_key(description: str) -> Optional[str]:
 # -> registry key. This is the device naming its own type -- no board-part
 # guessing involved -- so it's consulted before modelNum/description at all.
 #
-# Two provenance tiers, marked per entry:
-#   - "issue #N" -- seen verbatim in a real dump.
-#   - "OCF spec" -- not seen in a dump yet, but the OCF Smart Home Device
-#     Specification's Table 9-1 defines this exact `oic.d.*` string for this
-#     exact appliance category, and it's the same 'oic.d.<category>' shape
-#     as every issue-confirmed entry above it. Low-risk to add ahead of a
-#     dump precisely because that shape leaves no plausible alternative
-#     reading -- unlike a board-token table entry, there's no tokenizing or
-#     delimiter-spelling judgment call involved.
-#
 # Every value must already be a key in `_REGISTRY_BY_KEY` (checked by
 # `test_every_oic_type_resolves_to_a_real_registry`). That's why this list
 # stops well short of the full OCF/SmartThings device-type vocabulary: a
@@ -222,14 +212,14 @@ def _consumer_model_key(description: str) -> Optional[str]:
 # elsewhere in this codebase.
 _OIC_TYPE_TO_KEY: dict[str, str] = {
     'oic.d.airconditioner': 'airconditioner',
-    'oic.d.airpurifier': 'air_purifier',          # OCF spec
-    'oic.d.dishwasher': 'dishwasher',             # OCF spec
+    'oic.d.airpurifier': 'air_purifier',
+    'oic.d.dishwasher': 'dishwasher',
     'oic.d.dryer': 'dryer',
-    'oic.d.oven': 'oven',                         # OCF spec
+    'oic.d.oven': 'oven',
     'oic.d.refrigerator': 'refrigerator',
     'oic.d.washer': 'washer',
-    'x.com.st.d.stickcleaner': 'vacuum_station',  # issue #219 -- stick-vacuum clean station
-    'x.com.st.d.steamcloset': 'air_dresser',      # AirDresser / steam-closet garment care
+    'x.com.st.d.stickcleaner': 'vacuum_station',
+    'x.com.st.d.steamcloset': 'air_dresser',
 }