fix: GROUP BY sort record carries only needed columns, not full row

[iheitlager]

Summary

• compile_grouped_scan's pass 1 (src/codegen/select/aggregate.rs) built a full-width sort record per input row (one register/column per schema column) even after fix: GROUP BY aggregate (unindexed) is ~11x slower than SQLite oracle due to full-row column overhead in sort pipeline #506 taught columns_needed_for_projection which columns were actually needed — fix: GROUP BY aggregate (unindexed) is ~11x slower than SQLite oracle due to full-row column overhead in sort pipeline #506 only skipped the real Column/Rowid read for an unneeded column, substituting a cheap Null placeholder, because every downstream reader of the pass-2 pseudo cursor assumed the record still mirrored schema's original column layout 1:1.
• This closes that gap: compile_row_values_compact now emits only needed_order's columns (no Null padding at all), so MakeRecord/SorterInsert genuinely narrows. Pass 2's GROUP BY key reads, aggregate-argument compilation, and the plain-column "arbitrary row" snapshot all resolve against a compact_schema (a synthetic TableSchema covering only the needed columns, in order) — name-based Scope/compile_value resolution translates automatically, and the couple of by-index reads translate through an explicit compact_index_map (original schema index -> compacted position).
• flush_group's own synthetic schema/snapshot_regs stay full-width and untouched on purpose — that's a separate, per-group (not per-row) pseudo cursor, unaffected by this ticket's scope.
• hash.rs's unwired perf: implement Sorter opcodes for GROUP BY (4× gap vs oracle) #631 spike (dead code, kept for possible reuse) keeps its own pre-perf: GROUP BY/aggregate sorter records are full-row-width instead of narrowed to needed columns #665 copy of the old Null-padded helper rather than threading the same compaction through a path that's never actually invoked.

Verification

SELECT bucket, COUNT(*), SUM(x) FROM bench_data GROUP BY bucket's sorter MakeRecord is now MakeRecord|0|2 (bucket, x) — byte-for-byte matching sqlite3 3.53.4's own EXPLAIN output for the same query (also mkrec(r[11..12]), 2-wide), where it was previously 6-wide with 4 Null placeholders.

Test plan

• Added group_by_excludes_unreferenced_columns_from_the_sort_record — a 4-column fixture with one column referenced nowhere, asserting the sort record's MakeRecord width is exactly 3 (GROUP BY key + plain arbitrary-row column + aggregate argument, excluding the unreferenced column), plus correctness against the real oracle.
• cargo test --release — full suite green (980 tests, 0 failed).
• make test-corpus — 380 tests, byte-exact against the real oracle, all pass.
• make test-parity — 19 pass, 5 skipped (unimplemented V-blocks), 0 failed.
• cargo clippy --all-targets / cargo fmt --check — clean.
• cargo bench --bench crud -- read_group_by_agg — ~3.3% faster on the standard 6-column bench fixture (modest, since the fixture isn't very wide — the correctness win, matching oracle's opcode shape exactly, is the more solid deliverable; the remaining ~2.7x gap vs oracle on this scenario has a different root cause outside this ticket's scope).

Closes #665

spend: ~1x estimate — more involved than the issue's "small" estimate, since true record narrowing required a compacted synthetic schema/index-translation layer rather than just reusing #506's existing needed-columns analysis.