perf(notifications): skip re-enrichment of unchanged notifications

[joshfree]

Fixes part of #3101 (Improvement 1 of 3).

Problem

On every poll, getAllNotifications → enrichNotifications
(src/renderer/utils/notifications/notifications.ts) re-fetches subject
details for every visible notification, with no change detection. For N
visible notifications this issues ceil(N / 100) GraphQL detail queries every
interval even when nothing changed.

Change

Cache the enriched subject keyed by account + notification id + updatedAt. On
each poll, notifications whose updatedAt is unchanged reuse the cached subject
and only cache misses are sent to the batched enrichment path. The cached
subject is applied onto the freshly-listed notification so read state and
ordering stay current, and the cache is pruned each cycle to the
currently-present notifications so it stays bounded.

The change lives in the enrichment orchestrator above the adapter, so it is
forge-agnostic and preserves existing behavior for changed notifications.

Tests

Added coverage in notifications.test.ts for the skip-when-unchanged and
re-fetch-when-updatedAt-changes cases.

[setchy]

Thanks Josh.

One question - does the notification timestamp get updated when enriched details change? I looked into this 12-18 mths ago and have a faint (could be incorrect) recollection that there was something quirky about how the notification list data returns with respect to enriched details.

There was also some interesting notification timestamp behavior as notifications go from your unread inbox, to done/read, to being manually moved back to your inbox - so we'd need to go ensure our cache key handles this, too

[joshfree]

Hey @setchy -- thanks so much for taking the time to look at this, and for the thoughtful question — really appreciate it.

On the read/done -> back-to-inbox case: I think the current approach handles it, but you know the notification lifecycle far better than I do, so please tell me if I'm missing the quirk you ran into. The cache only stores the enriched subject and applies it back onto the fresh list item, so read/unread/done state and ordering still come straight from the live list. It also prunes to whatever's currently in the list each cycle, so anything that leaves and returns comes back as a miss and gets re-fetched.

On  updatedAt  not always moving: you're absolutely right, and I'll defer to you here. State changes and new comments bump it reliably, but things like labels, reactions, and milestones can change without it, so those could lag behind.

One idea, entirely subject to your preference: instead of a fixed timer (which is awkward anyway, since to actually save any calls it has to be longer than the poll interval, and that's user-configurable), we could tie freshness to the manual refresh -- background polling uses the cache, an explicit refresh clears it and re-enriches. But I'm very happy to go whichever way you think fits Gitify best.

How would you like me to handle it?