libpebble3: add calendar reminder vibration override

[kchinnasamy]

Summary

Adds NotificationConfig.overrideCalendarVibePattern: String? to mirror the existing overrideDefaultVibePattern (which covers notifications). When set, the named pattern is applied to every calendar reminder synced to the watch.

Also adds an optional vibePattern: List<UInt>? parameter to:

• CalendarEvent.toTimelineReminder(timestamp, pinUuid, vibePattern = null)
• CalendarEvent.toTimelinePin(calendar, supportsRsvpActions, vibePattern = null)

Both default to null — existing callers are unaffected.

Motivation

The notification path already supports a global vibration-pattern override via overrideDefaultVibePattern. Calendar reminders are the other major surface where a user might want to enforce a specific vibration style without per-app or per-event configuration. The symmetric overrideCalendarVibePattern field closes that gap.

PhoneCalendarSyncer is the only producer of calendar TimelinePin and TimelineReminder items in libpebble3, so the wiring is contained.

Implementation

Three files change:

• LibPebbleConfig.kt — adds one String? field to NotificationConfig.
• CalendarEvent.kt — toTimelineReminder and toTimelinePin both gain an optional vibePattern: List<UInt>? parameter. When non-null, the reminder / pin's attribute block appends vibrationPattern { it }.
• PhoneCalendarSyncer.kt — resolves the name in overrideCalendarVibePattern to the actual pattern bytes via VibePatternDao and passes them to both builders during sync. Also re-triggers a full calendar sync whenever the config changes, via a notificationConfigFlow.flow collector with .distinctUntilChanged().drop(1), so an in-flight override change immediately rewrites the existing pins on the watch instead of waiting for the next event modification.

Behavior notes

The watch fires the actual vibration from the TimelineReminder, not the TimelinePin — but the pattern is set on both for consistency (the pin's attribute is harmless when unused).

Backward compatibility

Non-breaking. New field and params all default to null; callers that don't set overrideCalendarVibePattern or pass vibePattern see no behavior change.

Test plan

• Set overrideCalendarVibePattern to a known pattern name → next calendar reminder on the watch fires with that pattern
• Unset the override → next reminder reverts to the bundled default
• Change the override mid-day → existing pins on the watch get rewritten (validates the reactive re-sync collector)
• Leave the override null → behavior identical to before this change

[CLAassistant]

All committers have signed the CLA.

[sjp4]

I don't think we should write this to the pin - it's not used and just a waste of bytes (BLE + stored in the watch blobdb)

[kchinnasamy]

@sjp4 Thanks for taking time to review the change and sorry for the late reply

I'd like to keep this on the pin, for two reasons:

1. Parity with the microPebble libpebble3 fork — the equivalent change there (matejdro/libpebble3) carries the override on both the pin and the reminder, and I'd rather keep the two lineages in lockstep so they don't drift.

2. Future-proofing at ~zero cost — it's optional and only written when an override is actually set (null otherwise → no attribute, no extra bytes in the default case). When it is set, it's one small attribute, and it leaves the door open if Core Devices ever wants a pin-level pattern.

You're right that the watch doesn't act on it today, so if you'd still prefer to keep the wire minimal I'm happy to drop it — just let me know and I'll remove it.

[sjp4]

Is this flow tested with a real watch (both when the vibe pattern changed, and when nothing changed)? The logic looks OK but it's the kind of thing which is complicated enough not to notice a bug..

[kchinnasamy]

Yes — this is the same implementation I've been running in microPebble (via matejdro/libpebble3) for ~2 months now, used daily on a real watch, so the calendar-reminder flow (including this dedup) has had a lot of real-world hours. Both cases behave as intended:

• Override changed → reminders re-sync and fire with the new pattern.
• Nothing changed → no reminder writes/churn — the recordHashCode() comparison skips unchanged ones.

The logic here is identical to the microPebble version, so it's well-exercised on hardware. Happy to re-verify any specific scenario you have in mind.