Support directional chain hops in anti-edge count rewrite

[adsharma]

Summary

Directional chain support. The anti-edge count rewrite previously required both triangle chain hops to be BOTH-direction extends, so LSQB q9 as written in the benchmark ((p1)-[:KNOWS]->(p2)-[:KNOWS]->(p3) with a directed anti-edge) never fired and ran a ~2.2s hash join plan. The T - S - A count arithmetic is now parameterized by the enumeration direction of each chain hop and of the anti-edge match (any FWD/BWD/BOTH combination):

• T = all chain tuples, weighted by per-node suffix path counts D
• S = n0 = n2 tuples (excluded by id(n0) <> id(n3))
• A = tuples where the anti-edge row exists, with row partners deduped per key pair (the mark is boolean)

Chain enumeration is row-level (a BOTH hop enumerates FWD rows then BWD rows, no dedup) to match the extend operator's semantics. Directions are recorded in LogicalCountAntiEdgeChain and plumbed through the plan mapper into the physical operator. Also fixes two latent bugs in the shape matcher (scanNode->getNodeID() is the internal-ID property, so ._ID-suffixed unique names never matched plain node variable names) plus build errors/warnings, and removes the LBUG_TRACE_ANTI trace scaffolding.

LBUG_DUMP_LOGICAL. The logical plan tree dumper is moved out of count_rel_table_optimizer.cpp into Optimizer::optimize, which every query goes through. With LBUG_DUMP_LOGICAL=1 the logical plan prints to stderr as a readable indented tree (one operator per line: extend directions, join keys/types, filter predicates, aggregate keys, scan targets) both before and after optimization — much easier to read than EXPLAIN's ASCII-art boxes.

Validation

• LSQB sf-like database, q9.cypher: fires the operator, returns the same count as the join plan (268837983); execution ~2219ms → ~23ms (~95x).
• Six direction combos (FWD/BWD/BOTH chains × FWD/BOTH anti-edge) cross-checked against the join-plan ground truth on the same database.
• LBUG_DUMP_LOGICAL smoke-tested on DDL, inserts, and reads.