[pixels-sink] Coalesce same-transaction primary-key changes within Retina RPC batches #21

A PostgreSQL transaction can legitimately update the same primary key twice (10 -> 20 -> 30), producing different total_order values. Adjacent updates currently share one Retina update group. Retina resolves all old locations before appending replacements, so both updates hide the same old location and leave the intermediate replacement unhidden.

Fold same-transaction, same-table, same-key operations within each RPC batch into their net I/U/D effect. Preserve transaction boundaries, earliest before image, final after image and original event counts for completion, including batches whose writes cancel. Retain ordered streaming between RPCs and add regressions for operation combinations, key changes and cancellation acknowledgements.

This is distinct from the native concurrent deletion-chain fix in pixelsdb/pixels#1412. A cds26 PostgreSQL/Debezium reproduction captured seven transactions and sixteen row changes; an RPC implementation test reproduced the intermediate-row visibility defect with mocked index/storage dependencies.