evalIndex is BFS-assigned (root = 0, descendants strictly larger), so a subtree's tokens are
contiguous in source order and every descendant carries a larger index than its subtree root. Two
sibling subtrees are always parted by a parent-owned token (an operator, separator, or paren) that
carries the smaller parent index — which is exactly where the ≥ scan stops. So hovering an
operator/function token yields the whole call it heads.
A range reference (A1:A3) reads as ONE unit here because the SDK gives every token of a reference
literal the reference root's evalIndex (mirroring how they share one referenceIndex) — so hovering a
corner evaluates the whole range, not the lone corner cell. That merge is the SDK's job, not this scan's.
Returns null for a token with no evalIndex (whitespace in an unparsed tail, punctuation the engine
couldn't place) — nothing to evaluate there.
The evaluable segment (AST subtree) that the token at
ibelongs to — the contiguous run of tokens whoseevalIndexstays ≥ the hovered token's, bounded on each side by an enclosing token with a smallerevalIndex(or the ends of the array).