Read an element's label and value without expanding the array

[ww-mw]

MAX_EXPANDED_ELEMENTS stops a 1000x1000 double from becoming a million table rows. That is right for the table and wrong for everything else: the only channel a consumer had for element-by-element display text was the child nodes, so capping expansion took the Variable Editor grid's data with it.

displayElements() is that channel as an accessor over _elements:

• Where element children exist, they are the answer — not a second derivation of it — so the two paths cannot drift apart. test/displayElements.test.ts pins the agreement between the paths rather than either one alone.
• Where they do not, one re-seeded scratch node formats each element through the same getter a child would have used, so the numeric precision, the char/string budgets and the <unavailable> sentinel stay single-sourced. Allocates nothing per element beyond the answer.
• null for a kind with no elements; [] for an array with none.
• Asking never creates a child, so reading the panel's data cannot undo the cap.

_elementType is now recorded before the cap guard, because a complex array is the one shape whose element class cannot be inferred from the container (_scalarType is double; the elements are complex).

Also closes two holes in the cap itself. The structured _array_type: 'String' parse and the bare JSON list of strings each built their element children with an inline loop instead of calling _buildStringChildren, so a 10,000-element string array expanded in full from those two spellings while the identical array written as an inline literal did not. Both go through the choke point now, and largeArrayNotExpanded.test.ts would notice a fourth spelling arriving with its own loop.

npm run verify green: 5136 tests.