test(parity): print the differing CALLS edges in the CI output - #1441

Makes the Database Parity Check failure diagnosable from the Actions log, per #1440.

REL_CALLS is the only metric that drifts, and a bare count can't distinguish "this backend dropped an edge" from "that backend wrote a duplicate". Each backend subprocess now also emits its CALLS edge set — keyed on source locations, not internal node ids, so the sets are comparable across backends — and the report prints per-backend totals, duplicate counts, and the edges unique to or missing from each.

REL_CALLS_DISTINCT is excluded from the pass/fail comparison; it's a diagnostic, not a parity metric. No behaviour change.

It already answers the question

Run locally against an isolated Neo4j, this narrows a spread of 2 to exactly two edges:

================= CALLS EDGE DIAGNOSTICS =================
kuzudb       total=648    distinct=637    duplicates=11
ladybugdb    total=648    distinct=637    duplicates=11
falkordb     total=647    distinct=636    duplicates=11
neo4j        total=649    distinct=638    duplicates=11

union=638  common-to-all=636  differing=2

--- MISSING from falkordb (2) ---
    sample_project_java/src/com/example/app/ToughCases.java:testAnonymous@42
        -> sample_project_kotlin/Main.kt:process@4 [call_line=54]
    sample_project_typescript/src/tough_cases.ts:loadModuleDynamically@29
        -> sample_project_typescript/src/tough_circular_b.ts:tough_circular_b.ts@None [call_line=31]

Both look wrong independently of any backend:

1. A Java → Kotlin edge. ToughCases.java:testAnonymous calling Main.kt:process — two unrelated fixture projects. languages_are_compatible is supposed to prevent cross-language CALLS; the audit spot-checked .py → .js/.java/.go and found none, so Java→Kotlin slipped through.
2. A callee that is a file, not a function. tough_circular_b.ts:tough_circular_b.ts@None — the callee's name is a filename and its line_number is null. That is the exact shape the existing tolerance comment blames for the drift ("cannot bind an exact called_line_number").

Neither is a legitimate edge, so the fix is to stop emitting them rather than to widen the tolerance. That also explains why backends disagree: unresolved edges with a null line are exactly what the fast/slow MATCH split handles differently.

Also surfaced: 11 duplicate edges on every backend (648 total vs 637 distinct by caller→callee@call_line). Consistent across all four, so it isn't a parity problem, but it may be worth checking whether those are genuinely multiple calls on one line.

What this PR does not do

It does not make the workflow pass. The tolerance is untouched — see #1440 for why I don't think widening it is right. This is the diagnostic that makes the real fix possible, and it will print on the next run so the numbers can be read straight from the Actions output.