fix: notifications are deduped in memory, not just in persistant storage

[LeosPrograms]

No description provided.

[zippy]

Some inline comments, and here are

Claude suggestions:

1. O(n²) dedup with double-serialization per comparison. moss-store.ts:742-748: the filter + inner findIndex walks the feed twice per element, and getNotificationFeedEntryId calls encodeAndStringify (msgpack + base64) on each side of every comparison. And because the surrounding for (const notification of notifications) calls _notificationFeed.update once per notification, you compound this across the batch. A single-pass Map keeps the "newest wins" semantics and is O(n):

this._notificationFeed.update((feed) => {
  const newEntry: MossNotification = { source, notification, sourceName: options.sourceName };
  const seen = new Map<string, MossNotification>();
  seen.set(getNotificationFeedEntryId(newEntry), newEntry);
  for (const entry of feed) {
    const id = getNotificationFeedEntryId(entry);
    if (!seen.has(id)) seen.set(id, entry);
  }
  return [...seen.values()].sort((a, b) => b.notification.timestamp - a.notification.timestamp);
});

2. Per-notification feed updates inside a batch loop. Since notifications can be an array, each one triggers its own _notificationFeed.update → re-sort → subscriber notification. For a batch of K notifications added against a feed of N entries, this is K separate sorts and K subscriber fan-outs. Could be hoisted to a single update that folds in all new entries at once. Not blocking, but cheap to fix while you're in there.

[zippy]

This value is breaking CI because it's not read. and the value is pulled in the loop at line 722, should be re-using this value unless nothing was pulled by the guard here. Need to think this through better.

[zippy]

inside loop this creates a n2 issue.