RETRIEVE WHERE clause with association-traversal expression as RHS comparand produces invalid XPath constraint (CE0161)

[MendixMau]

Environment:

• mxcli (upstream mendixlabs/mxcli): commit 504aec67
• mxcli (Engalar fork): commit 26f2866cb2dfa0089deb77ed54152a0238e11824
• Mendix Studio Pro: 11.12.0

Steps to reproduce:

create module ZKT39;
/
create persistent entity ZKT39.Category ("Name": String(100));
/
create persistent entity ZKT39.Product ("Name": String(100));
/
create association ZKT39.Product_Category
  from ZKT39.Product to ZKT39.Category
  type Reference
  owner Default;
/
create microflow ZKT39.ACT_FindSameCategory_Broken ($RefProduct: ZKT39.Product)
returns list of ZKT39.Category as $Categories
begin
  retrieve $Categories from ZKT39.Category
    where Name = $RefProduct/ZKT39.Product_Category/Name;
  return $Categories;
end;

Run mxcli exec repro.mdl -p EmptyTest.mpr, then validate with Studio Pro / mxbuild
(mx check EmptyTest.mpr or mxcli docker check -p EmptyTest.mpr).

Expected behavior: Either (a) the RETRIEVE compiles to a valid XPath constraint and the app
builds cleanly, or (b) if this pattern is genuinely inexpressible in Mendix XPath, mxcli check/exec should reject it up front with a clear MDL-level error, rather than silently
writing a microflow that only fails later in Studio Pro / mxbuild with a generic CE0161.

Actual behavior: mxcli check and mxcli exec accept the script with no warning on both
forks. DESCRIBE MICROFLOW shows the WHERE clause round-tripped as written. Running Studio
Pro's own validator against the resulting project reports:

[error] [CE0161] "Error(s) in XPath constraint." at Retrieve object(s) activity
  'Retrieve list of Category from database'

Isolated to exactly this construct — a parallel microflow using the documented workaround
(retrieve the associated object into its own variable first, then filter using that variable's
attribute — no traversal path inside the WHERE clause) compiles with no CE0161 on both forks.

Suggested fix: either (1) mxcli's expression-to-XPath serializer should detect a
multi-segment association-traversal path on the RHS of a WHERE comparison and rewrite it into
valid Mendix XPath (if that's structurally possible for this shape), or (2) if not possible,
mxcli check/exec should flag this construct explicitly (with the exact wording of the
workaround) rather than emitting silently-invalid output that Studio Pro rejects later. Since
this reproduces identically on both the upstream and Engalar builds, the fix likely belongs in
whatever shared expression/XPath-serialization code both forks still have in common.