John Dvorak
f5690d4777
updateRelationsBatch previously pre-sorted ops remove->modify->add, which changed the final state whenever one tuple was touched by mixed kinds: [add, remove] left the tuple present, [modify, add, modify] ended with the middle value. Now ops apply strictly in the given order via the dedup-aware _addRelationInternal (in-place last-write-wins) with upfront validation, post-batch PLTC edge updates, and per-relation arbiter-level cache invalidation. batch-order-parity.test.js pins the contract with an in-order mirror (modify-of-missing is a silent no-op).