fix(query): five defects that returned wrong answers without erroring - #1577

Each of these produced a plausible-looking result rather than a failure,
which is the class an agent cannot detect and will act on.

get_repository_stats inflated every per-repo count (#1529)

The per-repository branch counted CONTAINS *paths*, not nodes. The writer
creates File->CONTAINS->Function, Class->CONTAINS->Function and
Function->CONTAINS->Function, so every method is reached 2+ times. On a
live single-repo database this reported 2202 functions against 1551 real
Function nodes, while the tool's own global branch reported 1551 — two
branches of one tool disagreeing by 42%. The module counter already used
count(DISTINCT m); the file, function and class counters now do too.

find_callers misattributed callers across same-named functions (#1530)

target_file_path was hoisted to the envelope from the first row and
stripped from the rest, on the assumption it is constant. Without
`context`, who_calls_function matches Function {name} across every file,
so rows legitimately carry different targets and every caller was
reported as calling whichever definition sorted first. Now hoisted only
when the rows agree; otherwise the field stays per-row and the envelope
carries a note naming the ambiguity.

graph_name silently discarded for dead_code and find_complexity (#1531)

Both inner methods default graph_name to None and re-assign the shared
_active_graph, so omitting it at the dispatch site redirected the query
to the default graph. On FalkorDB — the default, multi-graph backend —
that returns results for the wrong repository with no error.

count(*) after OPTIONAL MATCH, and a phantom collect() entry (#1533)

An unmatched OPTIONAL MATCH still emits one null row, so count(*) meant
injection_count was never 0 and every Spring bean reported at least one
injector; now counts the bound relationship. Separately, a map literal is
non-null even when every field inside is null, so collect() kept an
all-null entry for a datasource with no key patterns; now collects the
node and projects afterwards.

add_code_to_graph advertised an argument it ignored (#1558)

graph_name is in the tool schema but the handler never read it, so an
agent could index into "service-a", be told it succeeded, and find
nothing there. Honouring it needs a per-job writer threaded through the
pipeline (GraphBuilder binds its GraphWriter to the default driver at
construction), so this refuses explicitly instead. Full support stays
open on #1558.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>