feat(sqlite): fold a replica's own objects into one so a shared bucket stops growing

[pal-tamas]

Without this a device's prefix accumulates an object per sync forever, and a device joining a year-old
family replays a year of them.

Stacked on #667 (→ #666 → #665). Retarget as those merge.

var removed = await engine.CompactAsync();   // or automatically, past CompactAfterObjects (default 50)

Why this is cheap — a property I checked rather than assumed

cr-sqlite's change feed is current state, not history. It holds one entry per (row, column) carrying
the value that won, so editing the same field forty times leaves one entry, and a deleted row collapses
to a single tombstone. Republishing everything therefore costs the size of the database rather than the
number of edits ever made.

Probed against the real extension before designing around it: 13 entries after an insert, still 13 after
five more edits, only the latest value present. Had it been an append-only log, folding a prefix into one
object would have been pointless and this would need a different design entirely.

Why it needs no coordination

A replica only ever rewrites its own prefix. The rule that removes write conflicts is the same rule
that makes compaction a purely local decision — no lock, no lease, no agreement about when it is safe.

Three things keep it correct, each pinned by a test:

• The replacement sorts at or after everything it replaces. A peer resumes from the last key it read,
  so a replacement sorting earlier would never be fetched — and since it is the only object left, that
  peer would silently stop receiving anything from this replica. This is the property the whole design
  rests on, so it is asserted directly rather than implied by a round trip.
• Re-reading state a peer already holds is harmless, because applying a change twice does nothing.
  That is what lets the replacement cover everything rather than only what is new.
• A peer reading an object as it is removed skips it and finds the replacement; the engine already
  treats a vanished object as ordinary rather than an error.

The replacement is written before anything is deleted: a crash between the two leaves duplicate state
in the bucket, which is harmless, where the other order could leave a peer with neither.

The empty case is deliberate

A replica whose local changes have all since been overwritten by peers — or whose rows were deleted, since
the tombstone carries the deleter's identity — contributes nothing. Its stale objects are removed and
nothing is written. The peers that now own those changes publish them, so nothing is lost.

Testing

Verified against two real replicas, not only the fake feed:

• forty edits to one field leave the feed exactly the size it was after the insert;
• a brand-new device reaching a compacted prefix gets the surviving row and stays free of the deleted
  one — a tombstone that did not survive compaction would resurrect deleted rows on every new device,
  which is the failure mode worth guarding.

dotnet test tests/Rask.SQLite.Crdt.Sync.Tests                          # 43 passed, 4 skipped
RASK_CRSQLITE_PATH=… dotnet test tests/Rask.SQLite.Crdt.Sync.Tests     # 49 passed

One expectation of mine was wrong and the code was right: compacting 8 objects removes 7, because the
replacement's key is the newest object's key and replaces it in place. Fixed the test, kept the
behaviour.

Local gates: dotnet format clean, dotnet build -warnaserror clean, 336 + 320 unit, 64 browser
journeys, 26 CLI build-gate.