perf: SorterInsert reads GROUP BY sort key from source registers

[iheitlager]

Summary

• Closes perf: SorterInsert re-decodes GROUP BY sort-key from the record blob it just built #660 (supersedes perf: reduce per-row allocations in hash-aggregation execution (HashAggFind/HashAggStep) #656, which wrongly targeted dead HashAgg* code — see perf: reduce per-row allocations in hash-aggregation execution (HashAggFind/HashAggStep) #656's closing comment)
• read_group_by_agg benchmarks ~3.3x slower than oracle (5.0-5.2ms vs ~1.5ms). Profiling (sample on the release bench binary) found SorterInsert re-decoding its own sort-key columns out of the record blob it had just been handed (decode_bytes_upto → parse_header_into/decode_serial_value) — even though those same values were still sitting in registers moments earlier, before MakeRecord encoded them. HashAggFind already avoids exactly this pattern via its own P3 (register-run) parameter; SorterInsert never got the same treatment.
• SorterInsert gains an optional p3 (source-register run), honored when p5 is nonzero — compile_grouped_scan's MakeRecord source registers are still live at that point (record_reg is allocated after them), so it opts in. Every other SorterInsert emitter (ORDER BY paths, join paths) leaves p5=0 and keeps the original decode-from-blob behavior untouched — purely additive to the opcode.
• Measured: group_by_agg bench ~3.5-4% faster at both fixture sizes (1mb: ~5.1ms → ~4.9ms; 50mb: ~284ms → ~274ms). Real but modest — remaining cost is dominated by the sort itself (compare::compare inside the stable sort, inherently O(n log n)) and row encode/decode during the scan, which are closer to structural floors. Filed as follow-up ideas in perf: SorterInsert re-decodes GROUP BY sort-key from the record blob it just built #660 if pursued further.

Test plan

• cargo test --lib — 976 passed
• cargo test --test '*' — full integration/oracle-parity suite, no failures
• cargo clippy --all-targets — clean
• cargo bench --bench engine -- group_by_agg — before/after comparison shows measurable improvement, no regression on other Sorter-backed paths (ORDER BY unaffected, p5=0 default preserved)

spend: ~1x estimate (small), plus the #656 diagnosis pass that preceded it.