feat(Tag Tracking+): Fetch a consistent number of posts

[marcustyphoon]

Description

This makes Tag Tracking+ fetch an arbitrary round number of posts, to match XKit 7's functionality (per user request).

I mean, no, obviously it doesn't; there's no API endpoint for that, and if there was, we would already be using it. This actually makes Tag Tracking+ fetch posts from a tag until it either a) finds a post the user has seen already, b) runs out of posts to fetch, or c) has fetched at least said arbitrary round number of posts, so that it can tell the user there are more than that number.

The "simplest" way I could think to implement this very-not-simple control flow was to early return out of a function when we definitively know the unread post count. There are definitely other ways to do it, possibly better ones; it's honestly quite a fun challenge to see what clear form you can find, IMO. Try it!

There's no minimum API delay implemented at present; with maxUnreadCount = 10 this at maximum doubles our normal API requests per second (as I observe 7 or 8 posts being fetched per request). I think XKit 7's count was 10... possibly maybe?

Split diff view is recommended.

Testing steps

• Confirm that Tag Tracking+ displays 10+ for tags with more than 10 unread posts and the correct number otherwise.

[marcustyphoon]

One can, of course, obfuscate the real counts less:

    if (!resource || posts.every(isUnread) === false) {
      return posts.filter(isUnread).length;
    }
  }
- return Infinity;
+ return `${posts.length}+`;
};

const refreshCount = async function (tag) {
  if (!trackedTags.includes(tag)) return;

  let unreadCountString = '⚠️';

  try {
-   const unreadCount = await getUnreadCount(tag);
-   unreadCountString = unreadCount > maxUnreadCount ? `${maxUnreadCount}+` : `${unreadCount}`;
+   unreadCountString = `${await getUnreadCount(tag)}`;
  } catch (exception) {
    console.error(exception);
  }

This results in, with current API responses, the maximum unread count appearing to be like 14-16 on a per-tag basis, which is sort of odd but doesn't throw away any information when the unread count is, say, 12. Dunno if that's better.