Fix update_advances? to be exact for delete-bearing updates

[jpcamara]

Prod issue

On docs with pure-delete retries, yrby-actioncable re-recorded and re-broadcast deletions the server had already integrated. Doc#update_advances? returned true for any delete-bearing update, so a lost-ack retry of a deletion looked like it advanced the doc every time — durable spam (duplicate rows, extra broadcasts, history-job noise) that the app had to compensate for with its own encode-and-compare guard around every write.

Root cause

Deletes don't move the state vector (a deletion tombstones an existing struct rather than adding one), so the cheap state-vector-growth probe couldn't tell a new deletion from an already-applied one. The old code took the safe-but-blunt route: any delete set ⇒ true (record it).

if !update.delete_set().is_empty() {
    return Ok(true); // can't cheaply prove a delete is a duplicate; record it
}

Fix

Measure the real effect on an isolated probe (never mutating the real doc), then branch on how to compare:

• Insert/format-only updates grow the state vector → compare that (cheap, unchanged).
• Delete-bearing updates → compare the full encoded document state (which carries the delete set) before vs. after the trial apply. A genuinely new deletion changes it (true); an already-applied retry re-encodes byte-identically (false).

Only delete-bearing frames — a minority — pay for the exact comparison. The exactly-once guarantee is unchanged in the safe direction: a real deletion is never dropped.

This flows straight through sync.rb's existing gate:

return :applied unless doc.update_advances?(update)  # now: dup pure-delete => :applied
sync_record_change(update)
sync_distribute(encoded)

A duplicate pure-delete frame is now acked but not stored or relayed — so the app-level replay-and-compare guard can be removed.

Tests

• protocol.rs — a pure-delete retry does not advance; a delete bundled with a new insert still advances (and its byte-identical retry does not).
• sync_test.rb — end-to-end ActionCable: a lost-ack delete retry is acked ([1,2,3]) but recorded/broadcast only once. Uses a new DeleteRetry fixture generated from real Y.js (added to generate_fixtures.mjs; the Y.js-emitted delete bytes match yrby's byte-for-byte).
• Full suite green: 77 Ruby runs, 17 Rust tests, clippy + rustfmt + rubocop clean.

Bumps yrby to 0.2.3.

Note: independent of the live-maps PR (#33). If that merges first, this needs a trivial version/CHANGELOG reconcile (0.2.3 → 0.3.x).

🤖 Generated with Claude Code