SQL persistence rewrites unchanged current execution rows #11710

Expected Behavior

After SQL persistence locks and validates a current_executions row, it should avoid a physical update when every value that would be persisted is already unchanged.

Actual Behavior

assertRunIDAndUpdateCurrentExecution always calls updateCurrentExecution after the required FOR UPDATE read and run-ID check. This emits an UPDATE even when the desired current-execution row is semantically identical to the locked row.

Repeated identical writes create avoidable WAL, tuple churn, and vacuum work. Skipping only the unchanged write preserves the existing row lock and all current-run validation semantics; any changed persisted field must continue through the existing update.

Steps to Reproduce the Problem

1. Persist a current execution row.
2. Invoke the update path with the same run ID and the same values for every persisted field.
3. Observe that UpdateCurrentExecutions is still called.

Time values need to be compared at the microsecond precision used by the SQL type converters, while all other persisted fields must match exactly.

Specifications

• Version: current main (9eadc90f60fd02fa2ee688bf5b29919b7fbb0dda)
• Platform: all SQL persistence plugins