Implement multi-parent packed scan for CSR rel tables

[adsharma]

Summary

Implements the deferred design from docs/multi_parent_lifetime.md: a multi-parent packed scan for the CSR rel scan path, plus the lifetime/representation documentation work it calls for.

Representation (PackedChildSlices)

• parentPositions (owned copy of only non-empty parents) → shared_ptr<SelectionVector> aliasing the bound (parent) chunk state's selection vector + prefix-sum offsets over all served parents (offsets.size() == parentSelSize + 1).
• Zero-length ranges (offsets[i] == offsets[i+1]) are allowed and must be skipped by consumers — the "drop parents without matches" invariant moves from scan time to the consumer, exactly as the doc describes.
• The shared_ptr keeps the SelectionVector object alive while still aliasing mutable contents, preserving the synchronous-consumption lifetime rule.

Storage (CSRNodeGroup)

• New CSRNodeGroupScanState::tryScanCachedTuplesPacked(): serves children of as many consecutive parents as fit into one output batch from the CSR row cache. Builds the combined (filtered) output selection vector, the per-parent prefix sum (RelTableScanState::packedChildOffsets), and the served-parent selection on the bound chunk state (switched to unflat).
• Handles zero-length CSR lists, capacity-limited partial lists, and cache-window boundaries; a parent whose list spans cache loads is resumed seamlessly across batches.
• All other scan paths (without-cache, in-memory, local storage, arrow/ice-disk/foreign) keep the one-parent-per-batch contract.

Operator & gating

• ScanRelTable::updatePackedChildSlices() attaches the descriptor for both batch shapes (derived from the bound vector's selection size); the speculative append/reserve machinery is removed.
• Multi-parent batches change the factorization contract (bound chunk unflat holding the served parents), so they are opt-in per consumer: the plan mapper enables it only for PackedFilteredCount consuming the scan output directly (dynamic_cast on the mapped child). Plans that fetch an nbr node property route through a hash join + FactorizedTable materialization — the exact materialization hazard the doc warns about — and correctly stay single-parent (verified empirically).

Consumer

• PackedFilteredCount attributes counts per parent via the packed slices when present (a batch may span many group keys); the legacy single-tuple cross-product path is preserved when no descriptor is attached (e.g. when the sink sits above the property-fetch hash join).

Tests

• Unit tests reworked for the new representation + a dedicated test documenting the aliasing semantics.
• New storage-level test drives RelTable::scan directly with packing enabled over a 3000-node / 6750-edge graph (degree 3, with zero-child parents): asserts multi-parent batches actually occur, the prefix-sum invariants hold, and every edge is served exactly once with correct parent attribution.
• SQL-level equivalence: the PackedFilteredCount pattern over an nbr property (join pipeline, single-parent batches) produces identical results with the packed extend on and off.

Docs

• docs/multi_parent_lifetime.md updated with an implementation-status note, including the materialization-boundary constraint that keeps the property-join plan shape single-parent.

Testing

• planner_tests (release + ASAN, DASSERTs exercised), rel_tests, and ~50 e2e test groups (match, filter, agg, generic_hash_join, dml_rel, cyclic, path, subquery, transaction, unwind, rel_group, acc, projection, …) all pass.
• clang-format-18 clean.