fix: silent zero-match predicates — guid equality and like over list columns

[protocolstardust]

Two select-where predicate shapes returned zero rows without any error, discovered while benchmarking filters over a 13.9M-row splayed table.

GUID equality predicates matched nothing

(select {from: t where: (== guid_col g)}) returned an empty result at any table size:

• the fused expression program has no 16-byte loads, so a compiled guid predicate read cells at the wrong width;
• the elementwise fallback routed guid cells through the numeric loops with the same outcome.

Fix: the expression compiler bails GUID columns (EXPR_BAIL_GUID, mirroring the existing RAY_STR bail), and exec_elementwise_binary gets a memcmp branch for ==/!= over guid operands. Ordering operators over guids raise a type error instead of comparing garbage.

like over splayed string columns: type error direct, silent all-false in where

Splayed string columns load as a list of string atoms (col_load_str_list). ray_like_fn rejected that shape (str-find accepts it), and exec_like's fallback memset the result to all-false — so a like predicate over such a column, or over any unsupported column type, silently matched nothing.

Fix: ray_like_fn gets the list branch (mirroring str-find's), exec_like delegates the list case to it, and the silent memset is replaced with the type error the direct builtin raises.

Tests

• test/rfl/query/guid_like_predicates.rfl — guid predicates find their rows, compose with aggregation, ordering raises; like over a list column in where; like over a numeric column raises.
• test/rfl/strop/like.rfl — list-of-string/symbol inputs, mixed-type list raises.

Benchmark (13.9M-row splayed table, 10 cores)

predicate	before	after
where (== LCID g)	0 rows / workaround via mask 479 ms	correct, 9.7 ms
where (like reason_text "*Pending*")	0 rows / workaround via str-find 121 ms	correct, 62 ms

Both now within ~1.5x of kdb+ on the same data (6.5 / 50 ms).