`exec` still writes an invalid `currentDeviceType()` expression even though `check` now flags it (MDL044)

[MendixMau]

Environment: mxcli (RnD/upstream, commit 504aec6), Mendix 11.12.0 project (EmptyTest base).

Steps to reproduce:

create module ZKT30;
/
create microflow ZKT30."MF_FunctionForm" () returns Boolean
begin
	if currentDeviceType() = 'Phone' then
		return true;
	else
		return false;
	end if;
end

Run mxcli check script.mdl (note it correctly reports MDL044 / CE0117 and exits 1), then run
mxcli exec script.mdl -p EmptyTest.mpr anyway.

Expected behavior: Given check already has enough information to identify
currentDeviceType() as an invalid expression function (MDL044 fires reliably, confirmed via
mdl/executor/validate_microflow_expr_test.go), exec should refuse to create/commit a
microflow whose body fails this same validation — or at minimum print the same MDL044 warning
during exec, not just during check.

Actual behavior: check reports the MDL044 finding and exits non-zero, correctly warning
that the build will fail CE0117. exec, run against the same script, does not run this
validation at all — it silently creates ZKT30.MF_FunctionForm with the invalid expression
baked in. A user who runs exec directly (or ignores/doesn't script-gate on check's exit code)
ends up with an .mpr that will fail to build in Studio Pro/mxbuild, with no warning from mxcli
itself at the point where the bad content was actually written.

Note this is not a request to add the MDL044 rule (it already exists and works well at check
time) — it's a request to wire the same validation into the exec path, or have exec bail out
when check-equivalent validation would have failed.

Separately, for context: engalar/mxcli (commit 26f2866) has no equivalent of MDL044 at all —
both check and exec accept currentDeviceType() silently there, so if this is ported
between forks, MDL044 itself (not just the exec-side gap) is the part engalar would need first.