Local matcher ORs merged `values` arrays; the GraphQL converter ANDs them

[TheHoneySeller]

Summary

The two sides of a data-block query disagree on what a top-level values array in a WhereCondition means when it holds conditions from different properties:

• Server path — core/io/converters.ts:325-335: multiple values conditions are ANDed ("each condition needs to be satisfied by at least one value").
• Local path — matchesValues in core/sync/experimental_query-layer.ts: uses conditions.some(...), i.e. OR.

mergePlainConditions in core/blocks/data/filter-state-to-where.ts (and master's mergeWhereConditions before it) concatenates values across property groups, so two text filters on two different properties become one merged array. Net effect: the "AND between property groups" guarantee holds for server-fetched rows but not for locally-matched optimistic ones (unpublished edits, freshly created rows).

spaces and types don't have this problem — both sides treat those arrays as OR.

Status

Pre-existing on master; surfaced during review of #2167 (per-property filter modes), which builds on the AND-between-groups guarantee. Not fixed there because it requires changing both sides to agree.

Options

1. Stop merging values across groups in mergePlainConditions — emit each property's values as its own AND child instead.
2. Make the local matcher AND a top-level values array, matching the converter.

Either way, add a test that runs the same filter state through both convertWhereConditionToEntityFilter and EntityQuery.where(...).execute() and asserts they agree.

Raised by @jwalkingjew in #2167 (comment).

🤖 Generated with Claude Code