Add measurement attribution 10

[Cyrus7]

Proposed Changes

Add the undocumented measurement attribution value 10 to MeasurementAttribution.

Evidence for what it means, from querying measure?action=getmeas directly on an affected account (Body Cardio + BPM Connect, aiowithings 3.1.6 via Home Assistant 2026.7.1): every Body Cardio weigh-in emits pulse wave velocity (meastype 91) as two measurement groups with the same timestamp —

{ "date": "2026-07-08T07:34:55Z", "attrib": 8,  "measures": [{ "type": 91, "value": 7705, "unit": -3, "position": null }] }
{ "date": "2026-07-08T07:34:55Z", "attrib": 10, "measures": [{ "type": 91, "value": 7721, "unit": -3, "position": 4 }] }

The attrib-8 group is the whole-body PWV; the attrib-10 group is the complementary per-position reading (position 4/5 = left/right foot). This confirms the observation in #86 that attrib 10 arrives with meastype 91: it marks a complementary/derived device measurement attached to a regular device session. This PR names it DEVICE_ENTRY_COMPLEMENTARY — happy to rename if you prefer something else (or if Withings ever documents it).

Today to_enum() maps 10 to UNKNOWN, aggregate_measurements() drops UNKNOWN groups, so the positional readings are silently discarded and every consumer poll re-logs the unsupported-value warning — users with daily weigh-ins get spammed (the linked HA issues report hundreds of warnings per day).

Adding the value follows the same pragmatism as the existing 8 -> 0 and 17 -> 15 remaps in from_api: a regular device measurement variant should not be dropped for lack of documentation.

Related Issues

Fixes #86
Related: home-assistant/core#148256

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.