Fixes
Device-remove path now ignores removes for the primary device (#801) The problem.patch_device_remove retained devices by filtering out the given device_id with no floor on the list. A remove notification targeting device 0 would delete its sender-key rows and persist a record with no device 0. Because get_user_devices treats any existing record as authoritative and only goes to the network when there is no record at all, the broken list would stick and suppress the usync re-fetch forever — the symmetric failure mode to the add-path bug fixed in #797.
The pre-existing device_id_u16 != 0 guard only skipped session cleanup for the primary; it did not prevent the registry removal or the sender-key-row delete.
The fix. patch_device_remove now returns immediately when device_id == 0. WA Web never drops the primary device, so a remove targeting it is treated as a no-op. This mirrors the invariant enforced on the add path since #797.
Impact. No API changes. No breaking changes. A device-remove notification for device 0 is an invalid notification that WA Web ignores; handling it as a no-op now matches that behavior.