`LwwRegister` concurrent merge uses document-level clock, causing silent data loss on uncontested LWW properties

[kkalass]

Affected Package

locorda_core

Steps to Reproduce

1. Installations A and B share a document at a common state: both at logicalTime=3.
2. A (offline) changes both schema:name AND schema:description → A: logicalTime=4, physicalTime=T1.
3. B (offline) changes only schema:name → B: logicalTime=4, physicalTime=T2 where T2 > T1.
4. A and B sync with each other.

Actual Behavior

LwwRegister.remoteMerge() computes ClockComparison.concurrent (each installation has logicalTime=4 for itself, neither has seen the other's entry). Tie-break falls back to maxPhysicalTime of the entire document: T2 > T1 → B wins all LWW properties. schema:description silently reverts to the pre-divergence value — B never changed it.

Expected Behavior

Each LWW property resolved independently:

• schema:name: both sides changed it → physical-time tie-break → B wins (T2 > T1) ✓
• schema:description: only A changed it → A wins unconditionally ✓

Platform

No response

Environment

No response

Additional Context

Root Cause:
The merge has no per-property change information available. Resolution granularity is the whole document. Two pieces of information are needed but currently missing or unused:

1. Per-property HLC in the document — when saving a LWW property, a metadata statement must be written recording the HLC at the time of that change (one statement per property, overwritten on each write → O(properties), bounded). This gives the remote side visibility into when each property was last changed.

2. Local DB query during concurrent merge — when ClockComparison.concurrent, for each LWW property:

   • Local side: query sync_property_changes table for whether/when this property was changed locally after the divergence point (the remote's last-known logical time for our installation)
   • Remote side: read the per-property HLC statement from the remote document
   • If only one side has a change after divergence → that side wins unconditionally
   • If both sides changed it → physical-time tie-break (same as current behavior, now scoped to actually contested properties only)

Both pieces are needed. The per-property document statement ensures both sides reach the same merge decision (convergence). The local DB query gives our own side's change timestamps without requiring them to be re-embedded in the document on every sync.

RemoteDocumentMerger already has an injected _storage field (currently // ignore: unused_field with the comment // Storage will be needed for property change history during actual merge) and LwwRegister.remoteMerge() already contains:

// TODO: what about augmenting the CRDT merge with the property change metadata from DB for more precise merges?

Both confirm the fix was anticipated.

[kkalass]

We need to first add a testcase to packages/locorda_core/test/assets/graph/all_tests.json which shows this bug by applying the steps to reproduce. It should not matter though which storage backend is used, so it should not matter if it is in singlefile, dataset or save test groups. Do note though that - if you let it record the assets, the test will probably seem to succeed, but only because the assets show the wrong behaviour/state. Please first generate them, then adjust them to show the correct behaviour and do an intermediate commit. Then fix the implementation until the (re)generated assets show the correct behaviour too