`check --references` REJECTS references that `exec` then WRITES, and the coverage is inconsistent

[marclehane-creator]

0.21.0 explicitly fixes one instance of this contract being inverted ("the check-syntax
skill promises exec refuses exactly what check rejects"). Measured against the new
resolvers the same release added, the contract is inverted again — in the other direction:

written	check --references	exec	mx check
image imgBad (Image: 'MyFirstModule.Images.NoSuchImage')	refused, exit 1 (and it lists the collection's real entries)	"Created page", exit 0	CE1613
SHOW PAGE ProbeSecond.NoSuchPage	refused, exit 1	"Created microflow", exit 0	CE1613
Action: MICROFLOW ProbeSecond.ACT_NoSuchFlow (CONTROL)	refused, exit 1	refused — failed to resolve microflow	—

The control is the finding. If exec simply did not resolve references, all three rows
would look alike; the third proves the exec-side guard exists and is merely not wired to the
image-entry or show-page-target resolvers. Both silent rows reached the build together
(The app contains: 2 errors.). Suggested fix: route these two resolvers through the same
function exec already uses for a button's microflow, as #1001 did for HOME PAGE … FOR.

---

mxcli 0.21.0 (mxcli-windows-amd64.exe, 2026-09-06 build), Mendix 11.11.0 / 11.12.x, Windows 11. Each item was re-measured on a fresh app with a control of the same construct type, and every mx check verdict is the literal The app contains: N errors. line. We keep the full register with repros in our repo; happy to share more detail.