Cypher: REMOVE of a property does not update the other aliases of the same node in the row, while SET does

[lvca]

Split out of the review of #6326, where the SET and REMOVE label paths were unified. This one is pre-existing and was deliberately left out of that PR: it changes REMOVE's observable semantics rather than fixing a crash, and it is unrelated to #6311/#6312/#6313.

SetStep calls propagateUpdateToSameNodeAliases() after writing a property, so every alias in the row that binds the same record is pointed at the updated MutableDocument and all of them observe the write. RemoveStep.removeProperty() does not: it replaces only the alias it was given.

MATCH (n {name:'a'}) MATCH (m {name:'a'})
REMOVE n.p
RETURN n.p AS throughN, m.p AS throughM

throughN is null, throughM still reports the removed value - the same query written with SET n.p = null answers null for both. Neo4j has one binding per node per row, so both aliases must see the same state.

Suggested fix: give the two steps one shared helper for pointing a row's aliases at an updated record, the way #6326 gave them one shared LabelReplacements for pointing them at a replaced one, and call it from removeProperty(). A regression test should cover both the two-alias case and the same node reached again on a later row.

[lvca]

Fixed in #6348, merged as 34482fd.

Done the way the issue suggested: propagateUpdateToSameNodeAliases moved out of SetStep into a shared RowAliases.propagateUpdate(row, original, updated), and RemoveStep.removeProperty() now calls it - one helper for pointing a row's aliases at an updated record, the way #6326 gave the two steps one shared LabelReplacements for pointing them at a replaced one.

One deliberate limit, recorded in the class javadoc: it redirects the row's own aliases and does not descend into records nested in a path, a list or a map. That is the difference from LabelReplacements.redirect, where the original record is deleted and a stale reference anywhere in the row is a failure waiting to happen, so the walk has to be paid for. Here the original is alive and merely older, which costs a stale read in an unusual shape rather than an error - and the walk would otherwise be charged to every row of every SET.

CypherRemovePropertyAliasIssue6328Test covers both cases the issue asked for - two aliases in one row, and the same node reached again on a later row via UNWIND - plus SET n.p = null answering identically, the removal still persisting, and a no-op removal leaving the other alias alone. Two of the five failed before the fix.