fix: detect Meter Pro CO2 from manufacturer_data alone (#299)

[bluetoothbot]

What

Identify the SwitchBot Meter Pro CO2 from its 16-byte manufacturer_data
signature when service_data is missing from the advertisement.

Why

Closes #299. The user reported that several of their Meter Pro CO2 devices were silently dropped from discovery. Some BLE proxies/scanners do not relay the SwitchBot service_data UUID; without a manufacturer_data fallback, parse_advertisement_data() returns None for those adverts. The user verified that adding manufacturer_data_length: 16 to the METER_PRO_C entry fixes detection on their setup.

How

• Add manufacturer_data_length: 16 on both METER_PRO_C entries ("5" and b"\x15") so _find_model_from_manufacturer_data recognises them.
• Reorder the lookup chain in _parse_data to try the service_data suffix before the manufacturer_data length match. Lock Vision / Lock Vision Pro / Lock Pro Wifi / Lock Ultra all share the 16-byte 2409 manufacturer_data shape but are uniquely identified by their 4-byte service_data suffix — the suffix must win when both are present.

Testing

• New test_meter_pro_c_no_service_data exercises the manufacturer_data-only path and asserts the device is identified as METER_PRO_C with correctly parsed temp/humidity/CO2.
• Full test suite passes (1214 tests).

🤖 Generated with Claude Code

---

Quality Report

Changes: 2 files changed, 44 insertions(+), 3 deletions(-)

Code scan: clean

Tests: passed (1214 passed)

Branch hygiene: clean

Generated by Kōan post-mission quality pipeline

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
switchbot/adv_parser.py	97.10% <100.00%> (-0.73%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bdraco]

@bluetoothbot gh_request

This only works if there is one device with 16 byte data length. The minute there is another device with 16 bytes this is wrong.

This PR should be closed. This is the wrong solution.

[bluetoothbot]

Acknowledged @bdraco — you're right. Length-only matching is fundamentally fragile (the 6-byte case already shares between Humidifier E/e entries; 16-byte would shadow the Lock Vision family). I'll defer to you on closing this; a proper fix would need a payload-byte discriminator inside manufacturer_data, not just a length match.