Leading and trailing spaces were silently inflating numTokens by one
boundary each, producing a lower norm value (0.707 instead of 1.0 for a
single-word field) and therefore a higher (worse) final search score for
any document whose field value contained stray whitespace.

Root cause: the original loop started numTokens at 1 and incremented on
every space→non-space transition. A leading space was treated as a
transition from an implicit word, so ' hello' gave numTokens=2 instead
of 1. Similarly, 'hello ' transitioned word→space near the end, giving
numTokens=2 even though only one word is present.

Fix: rewrite the counter to tally word-starts (non-space character that
follows a space or the string start). This is equivalent for typical
strings — 'hello world' still yields 2 — but correctly ignores leading
and trailing whitespace. Empty and all-whitespace strings are clamped to
1 to preserve the existing fallback behaviour.

Test: add a failing test that demonstrates the bug for ' hello',
'hello ', ' hello world ', and ' ', then verify it passes after fix.

BitapSearch.searchIn()'s exact-match fast path (pattern === text) returned
isMatch: true without checking minMatchCharLength, so a value that exactly
equals the query matched even when shorter than the configured minimum. The
fuzzy path already enforces this via convertMaskToIndices; the shortcut now
mirrors it, returning a non-match when text.length < minMatchCharLength.

Also covers the empty-pattern/empty-text case (default minMatchCharLength 1)
and the token-search path, which wraps per-term BitapSearch instances.

Closes #831

_searchObjectList and the keyless branch of _searchLogical scored off
FuseIndex.keys, which holds the raw user-supplied weights. Only KeyStore
normalises weights to sum to 1, so large weights pushed
Math.pow(Number.EPSILON, weight * norm) to underflow to 0, and absolute
scores diverged between plain-string, keyed-logical, and keyless-logical
queries over identical data.

Add _normalizedKeys(), which resolves each index key to its normalised
KeyStore counterpart by id, kept aligned to positional item[keyIndex] so
a pre-built index whose key order differs from options.keys still scores
correctly. Use it in both scoring paths, matching how the keyed logical
path already reads from the KeyStore.

Result ordering is unchanged (normalised score = raw^(1/T) for a global
constant T); only absolute scores for weights that do not sum to 1 shift,
and underflow is eliminated.

Closes #833

The word counter added in #830 only checked for charCode 32 (plain
ASCII space), so any field that separated words with a tab or
newline instead was scored as a single long word. That gives it an
artificially better field-length norm than a same-content field
using regular spaces - e.g. 'foo\tbar\tbaz' scores 20x better than
'foo bar baz' even though they're the same three words.

Added a small isWordSeparator helper covering the usual whitespace
range (tab/LF/VT/FF/CR, space, NBSP) instead of the single charCode
check, plus a test that fails without the fix.

…mment

Follow-up to #836. The isWordSeparator comment claimed "any whitespace
character" but the predicate only covers common ASCII whitespace plus NBSP,
not the full Unicode \s set (ideographic space, en/em spaces, U+2028/2029,
etc.). Narrow the wording so the scope reads as deliberate rather than an
oversight, and add assertions for CR, VT, FF, and NBSP to lock in the set
the predicate actually claims.

search(query, { limit: N }) selected the top-N with a max-heap that
ordered and evicted by raw score alone, ignoring the sortFn tie-break
and any custom sortFn. On a score tie at the cutoff it could drop the
item a full sort would keep, so the result differed from
search(query).slice(0, N).

Order the heap by the sort comparator and break comparator ties by item
index, applying the same tie-break to the full-sort path. The retained
top-N is now identical to a full sort followed by a slice for every
index, including reordered parseIndex records, and a custom sortFn is
honored. Gate the heap on shouldSort so shouldSort:false keeps
collection order.

Remove the now-redundant MaxHeap.shouldInsert (insert already guards)
and consolidate the sortFn casts into one typed assertion.

Reported in #835.