perf(table): sort from_data fold to avoid O(n^2) table builds

[smn]

What

Lua.encode!/2 (and any stdlib table built from a literal map) was O(n²) for lists and integer-keyed maps. This makes the build O(n log n), a ~38× speedup on the worst shape, with no behaviour change.

Root cause

Table.from_data/1 builds split array/hash storage by folding a plain map through put/3. It folded in map-iteration order — and any Erlang map over 32 entries iterates by key hash, not ascending:

Map.new(1..8, &{&1, &1})  |> Map.keys()  # [1, 2, 3, 4, 5, 6, 7, 8]   (flatmap, sorted)
Map.new(1..64, &{&1, &1}) |> Map.keys()  # [39, 59, 45, 50, 22, ...]  (hashmap, by hash)

So for N > 32 the dense integer keys arrived out of order. Each one missed put_array's contiguous fast path (key == arr_n + 1), parked in the hash, and was later drained by absorb_from_hash — where every drop_hash_key does an Enum.reject over an O(n) order list. N drains × O(n) reject = O(n²). String-keyed maps never hit this path (they insert_hash with an O(1) prepend), which is why only integer-keyed shapes regressed.

Fix

Fold the pairs in sorted order. Elixir term order places numbers before other keys and sorts integers ascending, so integer keys are inserted 1, 2, 3, … and every append takes the O(1) array path — nothing parks, nothing drains.

Enum.reduce(Enum.sort(data), table, fn {k, v}, acc -> put(acc, k, v) end)

Measurements

mix run benchmarks/encode_decode.exs, encode of int_list, per_elem_ns:

N	before	after
8	118	~148
64	568	~290
512	3179	~455
4096	22800	~600

Before: per-element cost grows with N (quadratic). After: roughly flat (linear). int_map and record_list collapse the same way; string_map and all decode rows are unchanged.

Tests

• mix test test/lua/vm/table_test.exs test/lua_test.exs — 129 passed.
• Adds benchmarks/encode_decode.exs, the harness that attributed the regression by direction / container shape / size.