Sync ako/mxcli: storage-GUID data loss and its write guard, MOVE/RENAME reference sweeps

[ako]

22 commits from the fork's main, on top of the last sync (57259e8). The bulk of it is one class of defect and the guard built to stop it recurring.

Storage GUIDs: silent data loss on every rewrite

An element's GUID is what the runtime keys the database on — mendixsystem$entity.id and mendixsystem$attribute.id hold it verbatim. Move it and the synchroniser treats the element as deleted-and-re-added: it drops the column (or the whole table) and loses the data. The model stays valid throughout, so mx check passes, the build succeeds, DESCRIBE is byte-identical, and nothing is visible until the package meets a database that already holds rows. Reported from production: 28 attributes of 607 rows emptied by one edit.

• Attributes and indexes on an entity rewrite (a3814c1, Any MDL write to an existing entity regenerates attribute storage GUIDs → Mendix DB sync drops and recreates every column (data loss) #1119) — every ALTER of an existing entity reset each attribute's GUID to its own $ID. This is the unclosed half of ALTER ENTITY ADD ATTRIBUTE drops system members (createdDate) on sibling generalization root — CE1613 across inheriting entities #657: that carried the target entity's raw bytes and relied on siblings surviving through the list-rebuild passthrough, but the target's own children are all rebuilt and nothing carried theirs. The correspondence is the stored $ID, not a structural pairing, which is what makes a RENAME carry the GUID forward — as Studio Pro does when it renames the column — while a genuinely new attribute correctly gets a fresh one. Every ALTER form routes through one function, so all six the report tested are covered, including SET DOCUMENTATION, which touches no attribute at all. Why nothing caught it for years: the corruption is idempotent. The bad GUID is derived from an $ID the transplant holds stable, so the second identical write is byte-identical, elision fires, and the run reports "Unchanged" — invisible to every same-vs-same check, including re-running the same script.
• A write that moves a GUID is now refused (76d0720) — three guards already at the write choke point could not see this: no-op elision compares a document with itself; the fresh-GUID test sees only one of the two codec mechanisms (the same blind spot that let Workflows$*.PersistentId through in Workflow activity PersistentId is re-minted on every write (never preserved, never read back) #949); and identityFields reaches only top-level properties, while these GUIDs sit on nested elements. The new guard pairs the two documents and reports any element whose GUID would change — cheap, at the moment the bytes would land, phrased as the message the user would otherwise never get. It deliberately does not repair: carrying a GUID on a tolerant structural pairing would trade a dropped column for something worse, a new member silently adopting a removed one's data under a name and type that no longer describe it. Wired into the shared reconcile step so both write choke points get it. One legitimate GUID writer exists and the guard found it on the first full-suite run — the marketplace module update, which is exactly what Studio Pro's own update does — and it opts out by name through the backend interface, with its own mock stub so a test cannot satisfy it by accident.
• Measured end to end on a live database (4f9ba5a) — Mendix 11.13.0 + PostgreSQL 16, a Studio Pro-authored entity seeded with 607 rows, pre-fix binary built from the parent commit so it is the real shipped path. One ALTER ENTITY … SET DOCUMENTATION: all three GUIDs became equal to their $ID, mx check reported 0 errors, and boot logged 14 synchronization commands with two columns going 607 → 0. The part nobody had measured: a recreated column with a model default is silently backfilled with that default. A boolean with default true read back as 607 non-null and looked untouched — until the run was repeated with every row seeded false, which came back true. So the loss can arrive wearing plausible data, count(col)