Fixes
Device list always retains primary after identity rotation (#797) The problem. When a device-add notification arrives with araw_id that differs from your stored value, patch_device_add clears the device list and rebuilds it from the notification. filter_devices_by_key_index only keeps device 0 if it is already present in the input. After the clear, device 0 is gone. The rebuilt list ends up as something like [{device_id: 19}], or empty if the notified device’s key index is rejected.
get_user_devices treats any existing record as authoritative. It only goes to the network when there is no record at all. So the broken list sticks. The self-healing usync re-fetch never fires. Every subsequent encrypted send to that contact skips their primary phone.
The fix. patch_device_add now unconditionally re-adds device 0 after every rebuild. This mirrors WAWebHandleAdvDeviceNotificationApi.handleDeviceAddNotification, which always pushes { id: DEFAULT_DEVICE_ID, keyIndex: 0 } back onto the list. whatsmeow enforces the same invariant.
Impact. If a contact performed a companion relink or identity rotation during your session, messages you sent afterward could silently miss their primary phone until the next full usync ran. No API changes. No breaking changes.