`mxcli check` doesn't flag `id = <String>` XPath retrieve constraints (CE0161 on real compile) — MDL048 exists in source but isn't in a release yet

[MendixMau]

Environment: mxcli v0.16.0 (official release) and Engalar fork commit 26f2866, Mendix 11.12.0 Beta, macOS arm64.

Mendix XPath's id pseudo-attribute compares object identity (GUID type). Comparing it to a String-typed variable or literal (as opposed to an object-typed variable, or the [%CurrentUser%] server token which Mendix resolves to a GUID) is a type mismatch that Studio Pro rejects at compile time with CE0161: "Error(s) in XPath constraint." Neither mxcli check --references nor mxcli exec catches this on the v0.16.0 release or on the Engalar fork — both accept the script silently and only the real mx check surfaces the error.

Steps to reproduce:

create module ZWLS45;
create entity ZWLS45.Item ( "Name": string(100) );
create microflow ZWLS45.ACT_LookupById ($GuidText: String)
returns ZWLS45.Item
begin
  retrieve $Found from ZWLS45.Item where [id = $GuidText] limit 1;
  return $Found;
end;

1. mxcli check script.mdl -p app.mpr --references → passes clean.
2. mxcli exec script.mdl -p app.mpr → succeeds.
3. mx check app.mpr → [CE0161] Error(s) in XPath constraint. at the retrieve activity.

Workaround: add a dedicated ExternalId (String, unique) business-key attribute to the entity, and retrieve/filter on ExternalId = $GuidText instead of id = $GuidText.

Note for the RnD maintainers specifically: your own repo already has a rule for this — mdl/executor/validate_microflow.go implements MDL048 (referenced as "ledger #42" in validate_microflow_hints_test.go), which is designed to flag [id = $Id] / [id = 'literal'] while correctly allowing [id != $ObjectVar] and [id = '[%CurrentUser%]']. It's wired into ValidateMicroflow(), which cmd_check.go calls during mxcli check. This doesn't appear in the CHANGELOG for any tagged release through v0.16.0 — please confirm whether it's shipped in a release yet and, if not, consider prioritizing its release since it directly closes this gap.

Separately (not the CE0161 bug, but hit while reproducing it): the RnD and Engalar forks have diverged on microflow body syntax — RnD uses begin ... end;, Engalar requires { ... } with returns <Type> as $var, and each fork's parser hard-rejects the other's form. Worth a compatibility note in whichever doc onboards users to "which mxcli am I running."