Generalize COUNT_REL_TABLE metadata counting to packed extend chains

[adsharma]

Problem

`COUNT(*)` over a long chain of extends (LSQB q1: 7 hops, packed path extend enabled) materializes 100M+ intermediate tuples and hash joins each hop:

Time: 14.50ms (compiling), 5645.25ms (executing)

The existing COUNT_REL_TABLE rewrite handles only a single hop (metadata count). Multi-hop chains get no benefit: every intermediate hop materializes neighbor IDs into data chunks and feeds hash joins, only for the result to be aggregated away.

Change

Add a CountRelTableOptimizer rewrite (tryRewriteExtendChainCount) that detects a pure path of >= 2 extends under a keyless COUNT(*) aggregate — hops may be connected by node-ID-only inner hash joins (packed INL join plans) — and replaces the whole subtree with a new count-only operator: LogicalCountExtendChain → CountExtendChain (physical).

Execution propagates per-node int64 count vectors hop by hop instead of materializing tuples:

c_0[v]      = 1 for every source node
c_{j+1}[w]  = sum over visible edges (v -> w) of rel table j of c_j[v]
result      = sum over last-hop edges of c_{N-1}[v]

• Each hop scans the rel table CSR with the direction keyed by the hop's from-node (FWD if from-node is the rel's src side, BWD if dst side), so the per-destination accumulation is a pure gather+add over the neighbor column.
• Only one int64 per node offset is carried between hops; neighbor IDs are read from the nbr column and consumed immediately — never materialized, no hash joins.
• Versioned deletions, in-memory CSR groups and local (uncommitted) rel data are handled by reusing the standard rel-table scan machinery (RelTableScanState), including multi-parent packed batches via packedChildOffsets.

Correctness gates (rewrite skipped otherwise)

• read-only transaction (uncommitted node inserts are not enumerated)
• no filters; scans carrying property predicates or primary-key scans restrict the node set and disqualify the rewrite
• extends not BOTH direction, single-entry storage-backed rel groups, single-table nodes
• the hop graph is a simple path (all degrees <= 2, connected, edges == nodes - 1)
• the subtree contains only row-count-invariant operators (projections, node-ID-only inner hash joins, scans); single-hop chains keep the cheaper existing COUNT_REL_TABLE rewrite

Results (ldbc_snb_sf1, 7-hop chain, count = 179,510,748 — identical before/after)

config	before	after
enable_packed_path_extend=true	5.65–5.84s	0.11–0.17s
enable_packed_path_extend=false	5.60–5.69s	0.11–0.11s

~35–50x faster. Chain-prefix cross-checks (2–7 hops, reversed chain) all produce identical counts vs the pre-change engine; filtered queries correctly fall back to the regular plan and match.

Testing

• Manual cross-validation against the pre-change binary on LDBC SNB sf1 (see above)
• Plan shows COUNT_EXTEND_CHAIN as a single-threaded source; filtered / GROUP BY queries unchanged
• LSQB test suite (test/test_files/lsqb/lsqb_queries.test) to be exercised in CI