perf: array-part constructor representation {tag, v0, v1} (#185) - #256

Closes #185.

What

A data-constructor value now compiles to a positional Lua table: the Module∷Type.Ctor tag string in slot 1 (sum types only) and the fields in the slots after it. Product types carry their fields from slot 1 with no tag, as before. The previous layout was a hash-part table, {["$ctor"] = "Data.Maybe∷Maybe.Just", value0 = x}, which hashed two string keys on every allocation and on every tag or field read. Tag reads now lower to e[1], field reads to e[i + 2] for sums and e[i + 1] for products. The tag stays the same interned string: the issue's measurements showed the win comes from the positional layout, not the tag type, and re-measuring confirms it (the int-tag variant is slightly slower than the string tag, not faster). On bench/micro/ctor_match.lua this machine shows a 0.124s median for hash vs 0.108s for array under PUC 5.1 (the issue's original measurement saw 1.4x on its hardware) and a 2x gap under LuaJIT. The generated output is also net smaller: the 43 regenerated goldens lose 700 lines and gain 493.

How

The issue expected a pure lowering change, but that premise didn't survive contact with the matcher: constructor field reads were emitted as ObjectProp scrutinee (PropName "valueN"), the same node genuine record access uses, so the lowering alone couldn't be re-pointed without breaking records. The matcher now emits the previously test-only DataArgumentByIndex node via a new TakeCtorField step, which also makes the IR honestly representation-abstract. The node gains the constructor's AlgebraicType, because the lowering needs sum-vs-product to pick the slot offset and has no type environment to ask at that stage.

In the optimizer, the ObjectProp-on-known-constructor fold branches (reduceKnownConstructor, propagateKnownCtorThroughLet, reduceKnownCtorRefRead) died with nothing emitting that shape and are removed together with the fieldIndex label-to-position helper. The DataArgumentByIndex folds instead require the read's algebraic type to match the constructor's: the type decides the runtime slot offset, so folding a mismatched read (necessarily ill-typed, but the fuzz suites generate such shapes) would return a different value than the compiled slot access reads. sinkProjectionIntoLet sinks field reads through a Let the way it sinks record projections, so the #180/#232 fold cascades stay intact.

The constructor table keeps positional rows on purpose: only a positional constructor pre-sizes the table's array part in PUC 5.1 ([i] = v keyed rows go through the hash path this change exists to avoid), and rows are always plain parameter names, which are single-valued in Lua even when nil, so a row can never splice multiple values.

FFI audit (checklist items 1 and 4)

The representation is FFI-visible, so before touching the compiler I grepped every surface for $ctor / value0..N reads, hand-built constructor tables, and generic table walkers over data values: the in-repo golden FFI files, the pinned .spago package-set sources, all fork clones (prelude Show/Eq/Ord FFI included), and the .purs sources for unsafeCoerce-to-record views. No representation-dependent code exists anywhere. The entire published FFI surface is constructor-abstract (constructors arrive as function parameters, in the _codePointAt(just)(nothing) style), and show/generic constructor names come from compile-time reflectSymbol literals, so the tag string never escapes into program output. No fork fixes and no package-set bump are needed; the changelog fragment records the break for third-party FFI authors.

Verification

The representation specs went in red-first (constructor table shapes, tag and field slot offsets, the algTy-mismatch decline, the field-read sink) and flipped green with the implementation. The full suite passes at 813 examples with the structural churn accepted: 23 golden.lua and 20 golden.ir move, and every eval/golden.txt oracle is byte-identical, which is the runtime-output proof that the flip changes the representation only and nothing depended on the old layout (checklist item 3). corefn.json inputs are untouched. ./bench/ci counter goldens (FNEW census and trace reports) are byte-identical too, so the change alters tables, not function prototypes or trace formation. The micro benchmarks are re-modelled so the array-part encoding is the measured current variant, with the hash layout kept as the baseline and the int-tag anti-result preserved.