Add xcxbike: proprietary FFF0/FFF6 telemetry bike and detection before FTMS

[cagnulein]

Motivation

• Some XCX-branded bikes (observed XCX-001048) expose a broken FTMS implementation while providing correct telemetry on a proprietary FFF0/FFF6 channel, so they must not be handled via generic FTMS.
• Implement a dedicated, read-only bike class to consume the proven 20-byte FA 05 FFF6 packets and expose speed, cadence, watts, energy, resistance and distance without inventing control commands.
• Ensure name-based detection for XCX- takes precedence over service-based FTMS detection so these peripherals are instantiated as the custom class rather than ftmsbike.

Description

• Added a new device implementation xcxbike with header and source: src/devices/xcxbike/xcxbike.h and src/devices/xcxbike/xcxbike.cpp, including an internal XcxTelemetry struct and a safe parseTelemetry() parser that validates packet length and header bytes and decodes fields using little-endian helpers.
• Service/characteristic handling discovers 0000FFF0-0000-1000-8000-00805F9B34FB and locates FFF5 (write) and FFF6 (notify) by UUID; it enables notifications on FFF6 by writing the CCCD 01 00 and does not send any writes to FFF5.
• Parsing rules implemented exactly as specified: speed = LE16(bytes 6..7) / 10.0, cadence = LE16(bytes 13..14), power = byte 17 (low byte only, documented), distanceRaw = LE24(bytes 8..10) and code uses distance = distanceRaw / 10.0 (km) rather than the firmware's FTMS metres interpretation.
• Detection/factory change: inserted a XCX- name branch in src/devices/bluetooth.cpp placed before the generic FTMS handling so XCX- devices are constructed as xcxbike.
• Project integration: added devices/xcxbike/xcxbike.cpp and devices/xcxbike/xcxbike.h to src/qdomyos-zwift.pri.
• Tests and test-data: added unit-style parser tests tst/Devices/TestXcxBikeParser.h and tst/Devices/TestXcxBikeParser.cpp (four supplied capture packets + rejection cases) and registered XCX-001048 in device test data index to expect xcxbike and explicitly exclude ftmsbike.
• Implementation is read-only for proprietary control: forceResistance, start/stop and FTMS control are not used or emulated; watts() returns zero when cadence is zero in line with repository conventions.

Testing

• Parser invariants: executed a Python validation that decoded all four supplied capture packets using the same parser logic (all 4 packets decoded and matched expected values). — succeeded.
• Static checks: ran git diff --cached --check and repository grep checks to confirm no forbidden writes or accidental FTMS usage are present in the new xcxbike code (no writeCharacteristic/2ad2/1826/ftms usages introduced). — succeeded.
• Detection precedence check: ran a script that verifies the inserted XCX- branch appears before the ftmsbike creation and instantiates xcxbike in that code path. — succeeded.
• Unit tests added: tst/Devices/TestXcxBikeParser.* were added to the test suite (tst/qdomyos-zwift-tests.pro) but the full Google Test build/run was not executed because the Qt build tools (qmake) and Qt development environment are not available in the execution environment. — not run due to missing qmake/Qt.
• Notes: attempts to call the local make_pr helper and run a packaged MCP helper failed due to environment/network restrictions; these are orthogonal to the code changes and do not affect the implementation or parser verification performed above.

Files changed (high level): src/devices/xcxbike/{xcxbike.h,xcxbike.cpp}, src/devices/bluetooth.cpp, src/devices/bluetooth.h, src/qdomyos-zwift.pri, tst/Devices/TestXcxBikeParser.*, tst/Devices/deviceindex.*, tst/Devices/devicetestdataindex.cpp.

If you want, I can run the full unit test build and/or tighten name-matching rules (e.g., restrict to XCX-001048) once a Qt/toolchain-enabled environment is available.

---

Codex Task

[cagnulein]

Mail blazsona