fix: keep the correct top-N under limit when scores tie

[spokodev]

search(query, { limit: N }) can return a different, worse-ordered top-N than search(query).slice(0, N) when scores tie at the cutoff. The heap that selects the top-N orders and evicts by raw score only, so it ignores the tie-break and any custom sortFn.

The documented contract, and the repo's own limit results match top-N of unlimited results test, is that a limited search returns the same items in the same order as an unlimited search truncated to N. The default sortFn breaks a score tie by ascending refIndex, but the heap evicts whatever sits at its root, which on a tie can be the lowest-refIndex (best) item, so the correct item is dropped. A custom sortFn is never consulted during eviction at all.

Repro

const fuse = new Fuse(['matchX', 'matchY', 'matchZ', 'match'], { threshold: 0.6 })
fuse.search('match').map(r => r.refIndex)              // [3, 0, 1, 2]
fuse.search('match', { limit: 2 }).map(r => r.refIndex)
// before: [3, 1]   (refIndex 0 dropped)
// after:  [3, 0]   (equals search().slice(0, 2))

Fix

Give MaxHeap the sort comparator and order and evict by it, so the worst retained item is the one that sorts last. The retained top-N is then identical to a full sort followed by a slice, and a custom sortFn is honored. src/ is the source of truth; dist/ is rebuilt with npm run build.

Added a tie-break case to test/optimizations.test.js. It fails before the change; the full suite (372) stays green, and typecheck, lint and format:check pass.

[krisk]

Your diagnosis was right: the heap ordered and evicted by raw score, so on a tie at the cutoff it ignored the tie-break and dropped the item a full sort would keep. The repro made it easy to confirm.

I've extended it a fair bit past your branch, so I'm landing it as a separate commit rather than merging directly. The same root cause turned up in a few more spots:

• A custom sortFn never got consulted during eviction, only at the final sort, so the retained set could be wrong, not just the order.
• limit ignored shouldSort, so search(q, { limit }) used the heap even under shouldSort: false and returned top-N by score when it should have kept collection order.
• Records can arrive out of idx order via Fuse.parseIndex, so I made idx the canonical tie-break on both the heap and the full sort.

Also dropped MaxHeap.shouldInsert (insert already guards), collapsed the sortFn casts, and added a regression test per case.

Closing in favor of that commit.