syncengine: count any edit after the last sync as a change

[ChakraFusion]

As agreed on #57: the narrow version of option 1.

Without a recorded merge base, DetectConflict compares each side's latest mtime with the last-synced time. A 2 s clock-skew allowance was added to that time. Edits made on both devices within 2 s after a sync therefore read as neither side having changed, and one replaced the other with no conflict raised.

Now any edit after the last sync counts as a change:

• Both sides changed: conflict, now including edits inside the old 2 s window. They are asked about instead of one silently replacing the other.
• One side changed: no conflict, and that side wins as it does now.
• Base recorded: unaffected. The content check runs first and doesn't look at clocks.

Why the allowance is dropped rather than moved before the sync. I tried that first, so that the 2 s before the stamp would count as a change too. It broke TestUntrackPropagatesAndRecovers and TestSwitch_TheSameGameUnderDifferentIDsSyncs (7 of 8 runs; 8 of 8 pass without it). A pulled file keeps the sender's mtime, which in a quick exchange is just before the stamp. The receiving device's untouched copy then counted as changed, so the sender's next edit became a conflict and nothing synced.

Tests:

• TestDetectConflict: the old "within tolerance does not count" case becomes three cases:
  • both sides edited within 2 s after the sync → conflict;
  • one side edited within 2 s after it → no conflict;
  • a copy written just before the sync → no change.
• TestMultiRootScenario_EditsRightAfterASyncStillConflict (e2e): stamps the two devices as synced, clears the location's base (as a lost report leaves it), and edits both sides at once.
  • Without the change: fails 3/3 with A="B-version" B="B-version".
  • With it: passes 4/4.

Trade-off: clocks are no longer given 2 s of slack. Suppose a device's clock is ahead and it holds an untouched file the other device wrote just before a sync. If the other device then edits before a base is recorded, that can be asked about as a conflict. This only applies while no base is recorded, and it is the "occasional extra prompt right after a sync" you said is the better failure.

Checks:

• Locally: the full unit and e2e suites pass.
• Fork CI: 9 of 10 jobs green. The tenth is one Windows e2e shard failing TestReportedWAN_AlternatingEditsMustNotConflict ("B's edit never reached A"), the push loop in Two devices push to each other forever when a save returns to an earlier state (since #42) #71. That test syncs a main save folder with a merge base, which doesn't reach this code.

🤖 Generated with Claude Code

[vercel]

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.