Proposal: keep the newest feed items when a news category fills

[mishan]

I'd like to propose a change to what happens when a feed category reaches the 65,535-byte article-list limit. The current behavior is documented and deliberate, so I've put this up as a proposal. I'm happy to rework it, or drop it if you'd prefer the current design.

What happens today. Items are imported oldest first, and the import stops at the limit. For a long-lived feed, such as a GitHub releases feed, that means:

• once the category fills, new releases never appear, and the category keeps showing the oldest ones;
• validators aren't saved while unseen items remain, so every later load downloads and parses the whole feed to import nothing.

The docs suggest splitting a large source across categories, but a single feed can't be split, and the category stops updating without anyone noticing.

What this PR does instead. When an addition wouldn't fit, the oldest imported articles are removed until it does:

• removed items stay recorded as seen, so they aren't imported again;
• local posts, and imported articles that have replies, are never removed;
• if those alone leave no room, the import stops as it does today.

A prerequisite. Pruning relies on the feed state's IDs naming imported articles, so new articles, local posts included, are now numbered above every ID the feed has used. Without that, deleting the newest article let the next post reuse its ID, and pruning could then remove a user's post.

Alternatives I considered and would be glad to switch to:

• a per-feed MaxArticles setting instead of pruning only at the limit;
• pruning only when the operator opts in.

Tests:

• the existing limit test, now asserting the newest item is kept and validators advance;
• local posts and a replied-to import surviving a prune;
• a local post not reusing a deleted import's ID.