Setting.apply uses cached=True so the persister is treated as the
source of truth and the device's live state never wins. That model is
correct for most settings, but it created a destructive bug for the
0x020D AdvancedParaEQ:
1. The V2 wire parser went through several iterations during G522
bring-up (commits bde3c3bc, 41db76bc, 59e3dcb7) with different
strides and gain encodings before settling at 7c73c888. Each
intermediate produced different decoded values from the same wire
response; whatever a user's Solaar was on when they last apply'd
got stored to the persister.
2. PerKeyLighting-style `prepare_write` silently fills missing band
keys with 0 dB and clamps out-of-range gain values to the
[gain_min, gain_max] rail. A partial/stale persister dict
therefore encodes as a complete wire payload — looking valid to
the device.
3. Writes were disabled in the early V2 builds (until be047fd9 on
May 10). Once writes shipped, the next apply read the stale
persister, prepare_write filled+clamped it, and setCustomEQ
slot 0 overwrote whatever the user had configured.
Observed on a G325 LIGHTSPEED user log: persister carried
`{0: -6, 1: 1094}` from an older build; apply pushed
`-6 +6 0 0 0 0 0 0 0 0` to slot 0 (band 1 clamped from 1094 to
the +6 dB rail, bands 2-9 zero-filled), wiping the user's
hand-tuned EQ.
Fix: override apply for HeadsetAdvancedEQ. Validate the persister
value against the current validator's count + gain range. If it's
well-formed, push it normally (preserves Solaar's "user config is
authoritative" model). If it's malformed (wrong key count, missing
indices, out-of-range gain), do a live device read and reseed both
_value and the persister from the device — without writing the
corrupt persister back. If both are invalid, log a warning and skip
this setting only; apply_all_settings continues with the rest.
045cccb8b2