Add Lenovo HS10 and Dr.Trust SSW526 support

[RealBhupesh]

What changed

• Add Lenovo HS10 support for the FFF0/FFF1/FFF4 history stream, including F2 00 history requests, ten-byte timestamp/weight/impedance decoding, duplicate protection, and consumed-history cleanup.
• Add Dr.Trust SSW526 support for the AC 27 FFB2 stream, including the captured offset-weight decoding, fixed-frame validation, stability detection, and weight publishing.
• Route both device-specific handlers before the generic MGB handler and narrow SSW532 matching so SSW526 is not misclaimed.
• Add focused protocol and handler-recognition tests.

Why

Issue #1437's HS10 capture showed the device's FFF0 service with FFF1 write and FFF4 notify characteristics but no measurement packet. The implementation follows the compatible HS11 packet reference and keeps the unverified hardware assumption explicit.

Issue #1436's SSW526 capture showed repeated AC 27 frames that the existing MGB/Taylor parsers ignored, so no measurement was published.

Validation

• git diff --check and committed-diff checks pass.
• Focused and full Gradle test commands were attempted, but local compilation is blocked because this checkout has no Android SDK/local.properties configured.

[oliexdev]

Thanks for your PR. Is something missing or why it is a draft version?

[RealBhupesh]

I kept this PR as a draft intentionally because two validation gaps remained: the local Android SDK was unavailable, so the Gradle tests could not compile, and GitHub had not reported any CI checks for the branch. In addition, the Lenovo HS10 implementation follows the compatible HS11 protocol reference because the issue capture contained no measurement packets, so it still needs physical HS10 hardware validation. The SSW526 path is based directly on the captured AC27 frames. I wanted those limitations to be visible before marking the PR ready for review.

[oliexdev]

The missing Android SDK isn't really a blocker — the easiest way is to just install Android Studio, it ships the SDK and sets everything up for you (open the android_app folder and you're ready to build). Alternatively you can install the command line tools and point local.properties at them with sdk.dir=…; after that ./gradlew assembleDebug test runs fine locally.

That said, from the code it looks like this PR was never actually run — neither built nor tried against a scale. Scale handlers are very hard to judge from review alone, so please test this with the real hardware, and let me know whether it works or not. Once we have that feedback I'm happy to take another look.