Store an edge row address in each CSR slot #73

Problem

A CSR slot holds only the neighbour key, so it can't point back to the edge row it came from. As a result:

• a hop that names its relationship variable (-[k:KNOWS]->) falls back to joins, even when it reads only one of k's properties;
• predicates that compare edge properties across the hops of a variable-length path (timestamps increasing along the path, say; "cross-iteration predicates" in feat: CSR adjacency index for native graph traversal (inspired by DuckPGQ + icebug-format) lance-format/lance-graph#159) can't be expressed on the CSR, and joins can't express them either;
• parallel edges between the same two nodes are kept as separate occurrences but have no identity, which relationship-uniqueness checks such as Two relationship variables in one pattern can bind the same edge #59 need.

Idea

Store each edge's Lance row address next to its neighbour, and fetch the requested relationship properties with take_rows, the way the fused target lookup already fetches node properties. The review of lance-format/lance-graph#162 makes the same point: adjacency entries need an edge row id for relationship properties and parallel-edge semantics.

This is Stage 1 of #72, which also relies on it to update a stored CSR after the old dataset version has been cleaned up.

To watch

• About 8 more bytes per edge per direction.
• A large, filtered hop can be slower as scattered take_rows than as one filtered scan and a hash join, especially in lazy mode. IC5's joinDate filter on hasMember is the benchmark query to watch.