test(dsl): add modern-graph regression tests for built-in graph algorithms

[CalebWang0126]

Fixes #794

What & why

Several built-in algorithms were never exercised on the standard modern graph by GQLAlgorithmTest: khop, closeness_centrality and lpa were only tested on ad-hoc graphs (g4/g5), and common_neighbors / jaccard_similarity had only a single parameter case. This PR adds five end-to-end CALL ... YIELD pairs on modern_graph.sql.

Expected outputs — verified by hand

The modern graph has vertices 1..6 and directed edges 1->2, 1->3, 1->4, 4->3, 4->5, 6->3 (algorithms using EdgeDirection.BOTH treat it as undirected).

• khop(1, 2) -> (1,0),(2,1),(3,1),(4,1),(5,2): BFS distances from vertex 1 within 2 hops; vertex 6 is unreachable. Consistent with the existing SSSP expectations on the same graph.
• closeness_centrality(1) -> 1.0: sum of shortest distances from 1 to reachable vertices = 1+1+1+2 = 5, and n-1 = 5, so 5/5 = 1.0.
• lpa() -> all vertices converge to label 1: simulated round by round; on ties the implementation keeps the lexicographically smallest label, which makes the outcome deterministic on this graph.
• common_neighbors(4, 6) -> 3: N(4) = {1,3,5}, N(6) = {3}, intersection = {3}.
• jaccard_similarity(1, 4) -> 0.2: N(1) = {2,3,4}, N(4) = {1,3,5}, intersection = {3}, union size = 5, so 1/5 = 0.2.

Test

mvn test -Dtest=GQLAlgorithmTest passes (39 tests, including the 5 new ones). Checkstyle passes.

Notes

While adding the jaccard case I noticed that for non-adjacent vertex pairs the algorithm always returns 0.0: common-neighbor confirmations are sent in iteration 2 but only reach vertex A in iteration 3, which the process() method does not handle. E.g. jaccard_similarity(4, 6) returns 0.0 although the mathematical value is 1/3. The existing (1,3) case passes only because 1 and 3 happen to be adjacent. This seems worth a separate issue; happy to file one if the maintainers agree.

Louvain / ASSP were intentionally not added: their tie-breaking depends on HashMap iteration order, which makes hand-verified expectations impractical.

[Leomrlin]

This expectation appears to lock in incorrect behavior for a disconnected directed graph. From vertex 1, only vertices 2, 3, 4, and 5 are reachable; vertex 6 is unreachable, and the sum of the finite distances is 1 + 1 + 1 + 2 = 5.

The current implementation counts all five other vertices in the numerator while omitting the unreachable distance from the denominator, which produces 1.0 and allows an unreachable vertex to inflate the centrality score.

Could we first define the intended semantics for disconnected graphs and then update both the implementation and this expectation? For example, Wasserman-Faust normalization would give (4 / 5) * (4 / 5) = 0.64 here, while the classical definition with an infinite distance would give 0.

[Leomrlin]

This case currently passes for the wrong reason and does not exercise the known non-adjacent-vertex path.

Because vertices 1 and 4 are directly adjacent, vertex 1 receives vertex 4's type-0 inquiry in iteration 2 and counts it as a common-neighbor confirmation. The actual common neighbor, vertex 3, sends its confirmation during iteration 2, so that message only arrives in iteration 3; however, JaccardSimilarity has no iteration-3 handler.

The incorrect intersection count is also 1, so the implementation happens to return the mathematically correct value 0.2. The existing (1, 3) test has the same adjacent-vertices/one-common-neighbor shape.

Please use a discriminating case such as (4, 6), whose expected result is 1 / 3, and fix the iteration-3 aggregation. If fixing the algorithm is outside this PR's scope, I suggest removing this case and tracking the bug in a separate linked issue.