fix(cypher): classify aggregation columns by is_aggregate_func, not a bare func check

[AmirF194]

What does this PR do?

Fixes the type(r)/count(*) half of #1111: RETURN/WITH aggregation misroutes non-aggregate functions into the aggregate-value branch whenever the query also carries an aggregate column, silently substituting the row count for the actual value.

MATCH ()-[r]->() RETURN type(r) AS tipo, count(*) AS n ORDER BY n DESC
# before: {"tipo":"176178","n":"176178"}   (row count in both columns)
# after:  {"tipo":"CALLS","n":176178}

Root cause

ret_agg_build_key/ret_agg_emit_row (RETURN) and with_agg_build_key/with_agg_find_or_create/with_agg_accumulate (WITH) classify each projected column with a bare if (item->func) check to decide "is this the aggregate column or the group-key column". That check is wrong: item->func is set for any function call, aggregate or not, so type(r), labels(n), id(n), keys(n), and properties(n) read as truthy and land in the aggregate branch next to real aggregates like count(*). There they are formatted by format_agg_value's default case, which emits the accumulated row count, not the value the query asked for.

The correct predicate already exists and is already used correctly one level up, where execute_return_clause/execute_with_clause decide whether a query needs aggregation at all: is_aggregate_func(), which checks the function name against the fixed aggregate set (COUNT/SUM/AVG/MIN/MAX/COLLECT). The per-column classification inside the aggregation-execution path never adopted it.

The fix

Swap the five item->func truthy checks for is_aggregate_func(item->func). A group-key column that carries a non-aggregate function now needs to actually evaluate that function instead of reading a raw variable/property, so its value comes from the existing project_item() helper (already used by the non-aggregated RETURN/WITH paths) rather than binding_get_virtual().

Verification

Docker (ubuntu:24.04, gcc, ASan+UBSan build):

• Reverted only the src/cypher/cypher.c hunk with the two new tests kept: both fail exactly as reported (type(r) and count(*) both return the row count).
• Restored the fix: both new tests pass; full cypher suite is 162/162.
• scripts/lint.sh --ci CLANG_FORMAT=clang-format-20 (cppcheck 2.20.0 + clang-format-20, matching _lint.yml): clean.
• scripts/security-audit.sh: passed, no new findings touching the changed files.
• Full unit suite (make -f Makefile.cbm test-par): 6770 passed, 12 failed, 4 skipped. The 12 failures (in subprocess, cli, mcp, index_supervisor, all process-tree/daemon-lifecycle tests unrelated to cypher.c) reproduce identically on unmodified main in the same container, so they predate this change.

Not verified: the other claim in #1111, an inline property map in a MATCH pattern silently matching 0 rows, does not reproduce on current HEAD and is unrelated to this fix. Leaving that open for you to split or close separately.

Fixes #1111

[DeusData]

Thanks, this is focused and the reported RETURN/WITH RED cases are good. One correctness regression remains before approval: scalar node functions now reach the existing bare-node carry path. labels(n), id(n), keys(n), or properties(n) can therefore leave the projected scalar alias carrying the original node ID, after which alias.property can incorrectly re-fetch the source node. Please make the carry predicate explicitly require a bare node projection, such as excluding items with func, and add a WITH-aggregation regression proving a scalar introspection alias cannot expose properties from the original node. The current head is otherwise DCO-clean, fully green, and introduces no new public surface.

[AmirF194]

Good catch, fixed in 5fb4c49. with_agg_find_or_create's bare-node-carry check only tested !property && variable, so labels(f) AS l (variable set, property NULL, func set) also got tagged with f's node id, and a later l.file_path hit node_prop's stub re-fetch heuristic and returned f's real file_path instead of empty.

Excluded items with func set from that carry path (only bare node variables like WITH g, count(*) should tag the id). Added cypher_issue1111_with_scalar_func_alias_no_node_leak: confirmed it fails on the prior commit (l.file_path returns "handler.go" instead of "") and passes with this fix. Full cypher suite (164 tests) green, lint and security-audit clean on the touched files.

[AmirF194]

The test-windows-guards failure here (test_windows_launcher.py, managed update secure-open error) is not from this branch: main failed the identical test the same way on 2026-07-24 (https://github.com/DeusData/codebase-memory-mcp/actions/runs/30067754814), and this PR only touches src/cypher/cypher.c and tests/test_cypher.c. Cause unknown beyond that, just flagging so it doesn't read as something this fix broke.