Shrink plans for comprehension-heavy queries such as IC10 #18

Problem

Queries built from pattern comprehensions, OPTIONAL MATCH, collect() and chained WITH produce very large physical plans. Two of them, IC10 and IC1, are where lance-csr trails other engines most; IC14 has the same plan growth, although it is already faster than the other engines.

Evidence

Physical operator counts on SF1, from explain():

IC10 collects each friend's posts and counts those that share a tag with the person, with size([p IN posts WHERE (p)-[:postHasTag]->()<-[:hasInterest]-(person)]). An earlier change (seeding comprehensions from the original rows) cut IC14 from 641 to 225 operators and from 188 to 62 ms, so there is precedent for large wins here.

Suggested fix

Start with IC10: read its logical plan and find where the comprehension and the OPTIONAL MATCH ... collect() are planned as separate joins and aggregations over the same rows. Candidates are evaluating a pattern predicate inside a list comprehension as a semi-join over the unnested list, and merging aggregations that group by the same keys.

Acceptance criteria

• IC10's operator count and latency before and after, in the pull request, with results unchanged.
• No regression on the other IC queries or the 30-query workload.
• Any new planning rule has focused tests.

Identified by profiling the LDBC IC benchmark; IC10's plan has not been analysed in detail.