Cypher multihop: expand direct variable-length support beyond endpoint-only patterns

[lmeyerov]

Current state

Direct Cypher now supports the narrow endpoint-only single variable-length relationship subset, for example MATCH (a)-[*2]->(b) RETURN b and typed/reverse/undirected variants.

Latest tests also make the remaining boundaries explicit:

• bounded/exact variable-length WHERE pattern predicates still fail fast
• mixed connected patterns where the variable-length relationship is not the only relationship in the connected pattern still fail fast
• named-path / path-value semantics remain separate work

Relevant coverage today:

• graphistry/tests/compute/gfql/cypher/test_lowering.py::test_string_cypher_failfast_rejects_bounded_variable_length_where_pattern_predicates
• graphistry/tests/compute/gfql/cypher/test_lowering.py::test_string_cypher_failfast_rejects_nonterminal_variable_length_relationship_patterns

Why track this separately

This is narrower than the broader GFQL path-semantics issue and is the next direct-Cypher parity step after the landed endpoint-only multihop subset.

Related but intentionally separate:

• #722 covers broader path naming / path tracking / path-sensitive predicate semantics
• #950 covers non-string params= research and is unrelated here

Desired scope

Expand direct Cypher variable-length support for the next user-visible families:

1. Positive bounded/exact variable-length WHERE pattern predicates, for example:

• MATCH (n) WHERE (n)-[:R*2]-() RETURN n
• MATCH (n) WHERE (n)<-[:R*1..2]-() RETURN n

2. Connected patterns where the variable-length relationship is not the only relationship in the connected pattern, for example:

• MATCH (a)-[:LIKES*2]->()-[:LIKES]->(c) RETURN c.name
• MATCH (a)-[:LIKES]->()-[:LIKES*3]->(c) RETURN c.name

Non-goals for this issue

Keep these out of scope unless they fall out cleanly:

• named path alias materialization like RETURN p
• path-value operators like length(p) / relationships(p)
• relationship alias list-carrier semantics like RETURN r or count(r)
• zero-hop *0 / *0..n forms unless explicitly designed

Success criteria

• parser/lowering/runtime accept the targeted direct-Cypher shapes above
• focused tests cover exact/ranged WHERE predicates and mixed connected patterns
• unsupported named-path / path-value cases continue to fail fast with explicit validation errors unless intentionally implemented
• user-facing docs are updated to widen the supported direct-Cypher multihop boundary accurately

[lmeyerov]

While testing official SNB Interactive query shapes from pyg-bench, I hit the zero-hop open-range case *0.. used by IS2. Since this issue explicitly leaves zero-hop forms out of scope, I opened #983 to track that gap separately.