OpenCypher: nested parameter field access ($param.field) in a MATCH pattern property map does not resolve #4909

Summary

In the OpenCypher engine, a nested parameter field access - $param.field - used as a property value inside a MATCH pattern does not resolve. The pattern matches nothing, with no error:

MATCH (source:Entity {uuid: $edge_data.source_uuid})
MATCH (target:Entity {uuid: $edge_data.target_uuid})
MERGE (source)-[e:RELATES_TO {uuid: $edge_data.uuid}]->(target)
SET e = $edge_data

The MERGE runs without exception but never creates the relationship, because the two MATCH clauses silently bind nothing. The same query with a top-level scalar parameter ({uuid: $source_uuid}) works, and wrapping the map in UNWIND [$edge_data] AS edge then referencing edge.source_uuid also works - which is the workaround the graphiti driver currently uses.

Diagnosed by @agc-63 while integrating the ArcadeDB backend for getzep/graphiti (verified against a real instance).

Root cause (to confirm)

engine/.../executor/steps/MatchNodeStep.java resolves a pattern property value only when it is a bare ParameterReference (whole-parameter substitution) or an Expression evaluated against a current input row. A $param.field map-field access is neither handled as a parameter nor evaluable without an input row, so the pattern property resolves to the wrong value (or is skipped) and the match fails silently.

Proposed fix

Resolve $param.field (parameter map/collection field access) in MATCH pattern property maps: evaluate the parameter-property-access expression against the input parameters even when there is no preceding input row, mirroring how UNWIND [$param] AS x + x.field already resolves. Add a regression test under engine/src/test/java/com/arcadedb/query/opencypher/.

Impact

Lets the graphiti driver drop its UNWIND [$edge_data] workaround for single edge saves and use the natural MATCH (... {uuid: $edge_data.source_uuid}) form.

Follow-up to #4905, flagged during review of #4906.