The feed's store read cannot fall off its index

[sepehr-safari]

Groundwork for #258, and worth having on its own. No behaviour change: the kind list is still {1}, and all 647 tests pass unchanged.

The cliff

The store picks its index on the product of authors and kinds (nostr/src/store.zig:481-487):

const pairs = std.math.mul(usize, authors.len, kinds.len) catch break :blk null;
if (pairs > max_merge_streams) break :blk null;

At or under 4096 it opens a cursor per author-kind pair on idx_author_kind and every candidate it yields was asked for. Over it, it drops to the plain author index and pays a decode for every event those authors ever wrote.

A full follow list is 2048 plus the reader:

kinds	pairs	index
{1}	2049	idx_author_kind
{1,6}	4098	falls back, full scan

It misses by two. So the moment the feed reads a second kind, which is exactly what #258 requires, a heavy follow list turns a feed rebuild into a scan of everything two thousand people have ever posted.

Why it would not have been caught

It breaks by getting slow, not by getting wrong, and only past roughly 1365 follows. Plaza own routing note measures a real account at 257 follows, which is 774 pairs across three kinds and perfectly fine. Nothing in this app knows where the store threshold is, so nothing here would have said a word.

The change

One query per kind, merged here, so the product is always authors times one whatever the kind list grows to. Robust by construction rather than correct up to a follow count nobody is watching. It also holds fewer cursors open at once, since the kinds are no longer multiplied together.

The merge is a linear pick across kinds.len cursors, which is three, and each kind already comes back newest-first. eventNewer orders exactly as the store does, ties broken by id, so the sequence is total rather than dependent on which cursor answered first.

Kept deliberately

A failed read still abandons the whole rebuild rather than skipping that kind. My first pass had it continue, which would have shown a feed silently missing everything of one kind: that reads as a quiet day rather than as a failure.

Next

The repost row itself: resolving the target from the store by its e tag, keying dedup on the reposted note rather than the wrapper, and taking counts from the target. All four reference clients agree on those three points.