csstype `(string & {})` open-arm materializes as a `{ ...JsxDOM.domProps }` bag inside opaque-module unions

[jagguji]

Summary

When a csstype value union that carries a genuine record/array arm can't collapse to string (e.g. Color | CustomArm, or a chart ColorString | GradientColorObject), it becomes an opaque %identity module — and the (string & {}) autocomplete open arm inside it is materialized as a DOM-attrs bag:

type …MixedRecordConfig = { ...JsxDOM.domProps }
external from…MixedRecordConfig: …MixedRecordConfig => t = "%identity"

For a Color/CSS value this is meaningless — the (string & {}) open arm reduces to string and carries no data, so modelling it as { ...JsxDOM.domProps } is wrong (just harmless, inside an allowed opaque module — no arm is dropped).

Pre-existing

Confirmed on main: the same shape is emitted for record-mixed csstype unions there (named …TokensTitleColorConfig). The #205/#206 fix (structural csstype detection + isForeignArm) did not introduce it, but its new fixture csstype-deeppartial-widening/expected/ now pins it as 'expected' — worth cleaning up so the golden doesn't enshrine the wrong shape.

Fix direction

In unionNode/the opaque-module path, recognise a (string & {}) / (number & {}) open-arm member (the same prototype-fingerprint / index-type test isForeignArm uses) and render it as the plain string/float from*/as* view, instead of building a { ...JsxDOM.domProps } record from its apparent object. Then refresh the csstype-deeppartial-widening golden.

Cosmetic/fidelity only; low priority. Surfaced during #209 review.