Sync ako/mxcli: two pluggable-widget defects, a stdlib toolchain bump, and a corrected parser claim

[ako]

Syncs 6 commits from ako/mxcli:main. Upstream is not ahead, so this fast-forwards.

Pluggable widgets — two independent defects on the same path

A conditionally shown property wrote a widget Mendix rejects (CE0463) (c8a483d). On ProgressCircle, both showLabel: true and labelType: 'percentage' produced it; showLabel: false and the same widget's General-group properties were clean. Three lines of MDL reproduce it — no DESCRIBE involved.

Two gaps, and closing either alone inverts the bug rather than fixing it:

• Serialization — Widget property conditional visibility from editorConfig.js (CE0463 on VideoPlayer + Timeline) #574 nulls the TextTemplate of a hidden conditional property but left a visible one null, where Mendix stores an empty Forms$ClientTemplate. Null and empty are each invalid in the other's state.
• Extraction — the editorConfig reader did not understand a ternary's else branch (cond ? (…) : hidePropertiesIn([…])), so showLabel's gate was never seen and labelText read as visible whenever labelType was "text", its default.

Filling visible templates without the missing gate simply moved which case failed. Both directions are measured, before and after. Only conditional properties are filled: Studio Pro's convention for an unset TextTemplate is not uniform — a DataGrid custom-content column stores null for tooltip and an empty template for exportValue — so filling every unset one would trade this bug for its mirror image.

A page carrying a pluggable widget could not be described and re-applied (9d0ac46). mxcli check on the description failed from the first widget onward with extraneous input ':', taking such pages out of the DESCRIBE-edit-CREATE OR REPLACE workflow mxcli documents as the way to change an element you did not author — and a widget has no other route.

• Emit — explicit properties went out through a raw %s, so every string lost its quotes; a JSON spec then broke the parse at its first brace.
• Read — extractExplicitProperties skipped any value of "true"/"false" as a "common default". A widget's default may be either, the document only stores what the author set, so the property was simply gone.

Fixed together because fixing one is worse than fixing neither: quote without emitting booleans and the description re-parses cleanly while silently dropping a property — a wrong page that validates. Quoting is decided by the declared type, never the value's shape: a String holding "30" is indistinguishable from an Integer once it's a string in BSON.

Both were diagnosed by handing the failing project to Mendix's own mx update-widgets on a copy and diffing against that reference — which named one meaningful path out of 969.

Build

• Go toolchain 1.26.5 → 1.26.6 (cad70cc). govulncheck ./... began failing with exit 3 on every push with nothing in mxcli changed: all six findings are stdlib advisories Found in: <pkg>@go1.26.5 / Fixed in: @go1.26.6, published between the last green run and the first red one. govulncheck@latest re-resolves the database each run, so the pinned toolchain went stale under an untouched workflow.
• Regenerate LSP completions for the FIRST keyword (64935d4). The import-mapping Range work added FIRST to the lexer but the committed completion list was never refreshed, so make build left a clean checkout dirty.

Correctness of the record

• A false claim about how Studio Pro stores a retrieve Range (8991344). parseRange carried the comment "Studio Pro stores custom ranges as ConstantRange with LimitExpression/OffsetExpression", plus a branch acting on it. Measured against a real document on 11.13.0, one retrieve per UI option: All → ConstantRange {SingleObject: false}, First → ConstantRange {SingleObject: true}, Custom(limit 4, offset 2) → CustomRange {LimitExpression, OffsetExpression}. LimitExpression never appears on a ConstantRange, so the branch had never fired.
• Proposal: derive container Size from contents (cd2b01e, docs only). A LoopedActivity's Size is computed from a pre-pass over the AST before its body is built, so it's a function of statement count alone and children's real positions — @position included — have no effect on the box meant to contain them. Measured on 11.6.6: children at x=150/310, x=1500/2000 and x=160/170 all yield Size 480;160; only the statement count moves it. In the x=1500/2000 case both children sit entirely outside their container and mx check reports nothing.