Summary

WINDOW JOIN with INCLUDE PREVAILING includes right-table rows within the time window plus the most recent right row with a timestamp equal to or earlier than the window start.

The non-vectorized fast cursor (WindowJoinWithPrevailingFastRecordCursor) compared the first window match against the window end instead of the window start, making the prevailing row effectively never included when the window already contained matches:

// bug: masterTimestampHi is the window end — since window rows always
// have ts <= windowEnd, this condition is never true
if (rowLo >= rowHi || slaveTimestamps.get(rowLo) > masterTimestampHi)

// fix: slaveTimestampLo is the window start, consistent with the
// vectorized cursor
if (rowLo >= rowHi || slaveTimestamps.get(rowLo) > slaveTimestampLo)

The vectorized variant (WindowJoinFastVectRecordCursor) already used the correct comparison. This bug only affected queries using non-vectorizable aggregates (e.g., max(concat(...))) with symbol-keyed WINDOW JOIN and INCLUDE PREVAILING.

Test plan

testFastNonVectorizedPrevailingWithWindowMatches uses max(concat(r.val, '')) to force the non-vectorized fast path with a prevailing row (val=99) outside the window alongside two window matches (val=20, 30).
Expects max="99"; without the fix, returns "30".
Cross-checks with vectorized count(*) expecting 3 rows.