LIKE 'prefix %' gives wrong results in WHERE filter vs projection when matching rows have multibyte chars after the prefix

[LaPingvino]

Bug

A LIKE predicate with a constant prefix that ends in a space (e.g. '## %') returns different results when used as a WHERE filter vs. as a SELECT projection, for rows that contain a multibyte (non-ASCII) character immediately after the prefix. The WHERE-filter path silently drops rows that genuinely match.

Minimal repro

CREATE TABLE m (id INT PRIMARY KEY, txt LONGTEXT);
INSERT INTO m VALUES (1, '## 中 body'), (2, 'plain');

SELECT COUNT(*)             FROM m WHERE txt LIKE '## %';  -- returns 0  ❌ (expected 1)
SELECT SUM(txt LIKE '## %') FROM m;                       -- returns 1  ✅
SELECT COUNT(*)             FROM m WHERE txt LIKE '##%';   -- returns 1  ✅ (no trailing space)

Row 1 ('## 中 body') clearly matches LIKE '## %' — and the projection (SUM(... LIKE ...)) and MySQL both agree it does (= 1). But the same predicate as a WHERE filter returns 0.

Observations / scope

• Triggered by a multibyte char right after the prefix. ASCII-only bodies are unaffected: (1,'## ASCII body') gives filter = projection = 1.
• Triggered by the trailing space + % form. LIKE '##%' (no trailing space before %) filters correctly.
• Reproduces with default collation and with utf8mb4_0900_bin and utf8mb4_0900_ai_ci.
• Reproduces at 2 rows and at scale: on a real 58k-row table, SELECT COUNT(*) ... WHERE text LIKE '## %' returned 53 while SELECT SUM(text LIKE '## %') returned 1490 on the same snapshot — a silent 1437-row undercount.

This looks like a constant-prefix LIKE → range-scan optimization that computes a wrong byte range when the prefix ends in a space and matching data has a multibyte byte sequence after it. Expected behavior: filter and projection agree (and match MySQL).

Version

dolt version 2.1.2

[elianddb]

@LaPingvino I'm creating a reproduction for this one, and testing against MySQL for parity. From a quick glance, it seems like we have divergent code paths. Once I get a PR up we can get a 24 hour fix in.

[elianddb]

@LaPingvino Fix is merged in our SQL engine, expect a release soon on Dolt!