Buffer lean rows in ORDER BY and GROUP BY to bound memory

[platypii]

Problem

Buffering operators (ORDER BY, GROUP BY) must hold their whole input in memory before they can emit. Late materialization means each buffered row is an AsyncRow carrying one cell closure per column, and those closures retain far more than the ~150 bytes of actual data. Measured on a streaming source (so the buffer is the only thing holding rows):

• ORDER BY 1M rows × 6 cols → ~1002 MB peak for ~48 bytes/row of real values.
• GROUP BY 1M rows → ~2 GB peak (OOMs under a 1 GB heap); it also spread each group's cell closures into per-group context rows.

Fix

Where a row is already fully materialized (resolved present), keep only the plain object and drop the per-column cell closures. The expression evaluator now reads columns from resolved first, falling back to lazy cells — safe because the planner only sets resolved when it completely and faithfully mirrors the output columns (never for derived expressions).

• Evaluator: readCell / hasCell helpers read resolved-first.
• ORDER BY: buffers lean rows (resolved + an empty cells map for cached derived sort keys), rebuilding full cells one row at a time only at emit.
• GROUP BY: buffers lean rows; the star projection and the HAVING/ORDER-BY context row read base columns from resolved; the context row is skipped entirely when neither HAVING nor a grouped ORDER BY needs it.

DISTINCT was left as-is: it already streams and only retains a dedup key-set (~152 MB for 1M rows), which is inherent to deduplication, not closure overhead.

Results (1M rows × 6 cols)

Operator	Peak heap before	Peak heap after	Time
ORDER BY	~1002 MB	~489 MB	5.0s → 2.5s
GROUP BY	~2 GB (OOM @1gb)	~1 GB (fits 1GB)	~3× faster

Both remain O(N) in row count — this halves the constant factor, it does not remove the buffer. Truly unbounded inputs still need spill-to-disk (separate work).

Testing

• All 1692 tests pass
• npx tsc clean, npm run lint clean