Fix Colmi R03 heart-rate history sync (timezone offset in 0x15 request)

[saksham2001]

Problem

A user's R03 (firmware RY03R_3.01.00_250611) pairs and syncs in PulseLoop but heart rate never appears, while QRing shows HR fine. Their diagnostics log shows clean connects, sync chains finishing in ~24s, zero errors — and zero HR data: the ring was replying to the HR-history stage with empty markers for every requested day.

Root cause

The ring's RTC is set with plain local wall time (setDateTime, no timezone), so its firmware keys HR-history days by local-time-as-UTC epochs. Both working reference implementations build the 0x15 request accordingly:

• GadgetBridge (YawellRingDeviceSupport.fetchHistoryHR): getTimeInMillis() + ZONE_OFFSET + DST_OFFSET
• colmi_r02_client: midnight of the target date with tzinfo=UTC

PulseLoop sent the true epoch of local midnight. On strict 3.x firmware the mismatched timestamp finds no day slot → empty reply, silently. HR is the only Colmi history stage whose request encodes a timestamp (activity/HRV use day indexes, stress takes none, SpO2/sleep/temp are big-data), which is why only HR failed.

Older-firmware rings (R02/R09/R11/R12 fleet) tolerate the mismatch — for west-of-UTC users the old timestamp still lands inside the correct ring-frame day — which is why this only surfaced now. The corrected form is byte-for-byte what QRing/GadgetBridge send to every model, so it cannot regress working rings.

Changes

• ColmiEncoder.syncHeartRate now takes the day Date and adds secondsFromGMT (mirrors the Jring makeTimeSyncCommand idiom); contract documented at the byte layout.
• ColmiSyncEngine.requestHeartRate() passes syncDay directly.
• New ColmiEncoderTests: +8 zone, DST-aware negative zone, GMT identity.

Net behavioral change: 4 timestamp bytes in one request.

Testing

• ColmiEncoderTests + full ColmiDecoderTests suite pass on the iOS simulator.
• Hardware confirmation pending from the reporter's R03.