Inline property map in MATCH pattern silently matches nothing — should error if unsupported

[junk151516]

Environment: v0.9.0, Windows amd64, --mode moderate index.

Summary: Using an inline property map inside a MATCH pattern returns an empty result set with the generic "no results" hint, while the equivalent WHERE clause returns rows. If the Cypher subset doesn't support inline property maps, this should be a parse/validation error — silently returning 0 rows makes LLM agents (the main consumers of this tool) conclude the edges don't exist.

Repro

cli query_graph --project P --query "MATCH (a)-[r:CALLS]->(b {name: 'auto_match'}) RETURN a.qualified_name"
# → {"rows":[],"total":0,"hint":"Query returned no results..."}      ← silent empty

cli query_graph --project P --query "MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'auto_match' RETURN a.qualified_name"
# → 2 rows (correct)

Related: RETURN type(r) also doesn't resolve (returns the row count in both columns instead of the relationship type) — same "unsupported syntax should error, not mislead" argument:

cli query_graph --project P --query "MATCH ()-[r]->() RETURN type(r) AS tipo, count(*) AS n ORDER BY n DESC"
# → {"columns":["tipo","n"],"rows":[["176178","176178"]],"total":1}

Suggested fix: either support inline property maps (they're the most common Cypher idiom LLMs emit) or reject them with an explicit error listing the supported subset.

[DeusData]

Thanks for the precise paired queries. This is a high-priority 0.9.1-rc correctness bug: unsupported syntax must not silently produce authoritative-looking empty or fabricated results. Please keep the inline property-map case and type(r) case as separate RED assertions because they exercise different parser/evaluator paths. The fix may implement the syntax or fail closed with a specific unsupported-syntax error, but it must not return a successful misleading result.