fix(device): don't reset cache timestamp when setting values
Since the original changes to make the predecessor async, the integration has reset
the cache updated_at to 0 in _set_values(), presumably to force an update ASAP.
Previously this did not interfere with updates, so something else must have been
resetting it to a proper timestamp before the receive loop saw it and revertted to
polling, but starting with 2026.4 release, we started seeing communication issues,
especially from protocol version 3.4 devices.
Thanks to @kishorviswanathan for pointing Claude in right direction in issue #4965
Most likely a fix for #5347, #5346, #5109
Possible fix for earlier issues #3827, #1323