2 Commits (847a28df3e273bb08c2dddf3628468f4face4d9a)

Author	SHA1	Message	Date
Strycher	b4fe9c145b	fix(#283): summarise the same GIF set the chat renders ... formatNotificationText used GifHelper.parseGif (Giphy only) while the chat renders via resolveGifUrl (Giphy + allowlisted Tenor CDN). An allowlisted Tenor GIF therefore rendered inline but still dumped a raw URL into the notification tray. Point both at resolveGifUrl so the tray summarises exactly the set the chat displays. Off-allowlist URLs still pass through as plain text, pinned by test. This is the same duplicate-detection drift that caused #284; closing it at the source rather than shipping a known inconsistency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 days ago
Strycher	af6485f2e3	fix(#284): summarise GIF notifications via GifHelper, not a duplicate regex ... Notifications summarised a GIF as "Sent a GIF" using their own hand-rolled `^g:[A-Za-z0-9_-]+$` regex rather than GifHelper. #282 changed the payload to `https://giphy.com/gifs/<id>`, which that regex does not match, so GIF notifications regressed to dumping the raw URL into the tray. Detection now goes through `GifHelper.parseGif`, matching how the adjacent reaction case already delegates to ReactionHelper. That restores the summary and covers every form the app can send, including replies (`@[Name] ` + payload), which the old regex never matched even for legacy `g:<id>`. Verified no other hand-rolled `^g:`/`^m:`/`^s:`/`^r:` payload regexes remain outside their owning helpers, so this class of drift is closed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 days ago