Support OTA updates for devices exposing OTA as a server cluster - #1915

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.52%. Comparing base (2fdc4ab) to head (237a01a).

@@           Coverage Diff           @@
##              dev    #1915   +/-   ##
=======================================
  Coverage   99.51%   99.52%           
=======================================
  Files          61       61           
  Lines       12777    12790   +13     
=======================================
+ Hits        12715    12729   +14     
+ Misses         62       61    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@zigpy-review-bot Alternatively, think about if we should just always swap a server OTA cluster to a client cluster on all devices zigpy-sided, since none should really have server ones in the first place. (Note there's an ongoing review session for this PR, so possibly communicate with that session: review <=> process mentions.)

I looked into it. In short, a blanket swap wouldn't be a simpler replacement for this PR. The descriptor it would change is what quirks match on, so it needs quirk-side care and more zigpy code than find_ota_cluster() + send_direction. I'd keep the PR's approach.

What a swap would gain

• Incoming OTA frames from these devices would hit the client cluster directly, so OTA would no longer depend on the direction-flip fallback in _find_zcl_cluster (the one whose comment says it will be removed).
• ZHA would use the normal FirmwareUpdateEntity, and FirmwareUpdateServerEntity plus the server-side diagnostics handling could go away later. The update entity's unique ID is <ieee>-<ep>-25-firmware_update for both classes, so no registry orphans.

What it breaks or needs

• Quirk matching. v1 signatures compare cluster sets exactly (set(a) == set(b), zhaquirks/legacy/__init__.py:91), and 12 v1 quirk files list OTA as an input cluster. That includes the 3RSS007Z's own quirk (zhaquirks/thirdreality/switch.py) and several Xiaomi devices (cube, sensor_ht, magnet, motion, …). A swap before matching stops those quirks from matching. Swapping between matching and replacement doesn't work either, because the replacements add OTA back as an input cluster. In v2, the Candeo quirks call .removes(Ota.cluster_id), which defaults to the server cluster, so a pre-quirk swap would make that removal miss. Those devices would then get an update entity their quirk deliberately drops.
• So it has to run after quirk resolution, on the final device, in both paths: _finalize_device for joins/re-interviews and appdb.load() after _resolve_device. original_signature and the DB rows then keep the reported descriptor. Attribute-cache rows are keyed by cluster type, so cached OTA attributes from the server cluster are skipped on load unless they're remapped.
• It doesn't remove the _discover part. _discover runs on the raw device before resolution, so the join/re-interview OTA read still needs its own fallback, with the coordinator guard. Without that, the PR's "Known limitation" stays the same with or without the swap.
• Coordinator. zigpy registers OTA as an input cluster on its own endpoint (zigpy/application.py:1016), and bellows/znp initialize the coordinator on startup. It has to be exempt, or it reads OTA attributes from itself, which is the failure this PR already has a regression test for.
• OTA in both directions. Some devices list OTA as both input and output (Eurotronic SPZB0001, Xiaomi cube). Only server-only endpoints should be touched. Where both exist, the PR's client-first lookup already picks the client.
• Object. It needs a fresh client Ota instance rather than moving the server one (cluster type is fixed at construction), plus the endpoint attribute/DB listener registration that add_output_cluster does.
• "None should have server ones" holds for end devices. A remote device that really runs an OTA server (another gateway on the network) would be misrepresented. That's rare, but a blanket rule can't tell the difference.

If you want it anyway, the minimal safe version is a post-resolution normalizer for non-coordinator devices. It would only touch server-only OTA endpoints and create a fresh client Ota, with signature and DB rows left as reported, plus the _discover fallback. That's more code than this PR, and its main payoff is not depending on the direction-flip fallback. I'd only go that route once that fallback is actually being removed.