native: save() overwrites a record changed after it was read (lost update) #172

On the native build, save() of a record object overwrites a record that another transaction changed after the object was read, and silently reverts that transaction's committed values (a lost update). The JVM build refuses the save with ConcurrentModificationException.

Scenario (a probe run on the 26.11.1.dev0 dev wheels, Linux x86-64): a document with a = 1, b = 1 is read and turned into a mutable object with db.lookup_by_rid(rid).modify(); another transaction sets b = 2 and commits; then a = 10 is set on the object and save() is called in a transaction.

Cause: native save() of an existing record runs UPDATE <rid> MERGE :row with the Python snapshot of every property (src/arcadedb/_native/records.py), and carries nothing that identifies the image it was read from. The engine has no record version; the JVM check is the engine's own comparison of the bytes a MutableDocument was read from with the bytes stored now (TransactionContext.checkRecordIsStillTheOneRead).

Fix in progress: the native glue fingerprints the stored record bytes when a record row is read and checks the fingerprint in the same transaction as the update, raising the engine's ConcurrentModificationException on a mismatch. Because the fingerprint would be computed for every record row a read returns, the change gets a timed A/B of the read paths before a PR, so the read speed of the native build is not traded silently for this check.