Sync can silently diverge when Dropbox or WebDAV changes occur within the same second #1058

Bug Description

Dropbox and WebDAV use second-precision modification times. In syncFile(), if the local and remote timestamps are equal at the backend's declared precision, the function returns without reading or comparing the remote content.

This means two different versions modified within the same second can be treated as already synchronized.

I found this while tracing the current sync implementation. I have not reproduced it with two physical devices yet.

Steps to Reproduce

A deterministic code-level case is:

Use a sync backend with modifiedTimePrecision: "second".
Local content is A, modified at 12:00:00.200.
Remote content is B, modified at 12:00:00.800.
Run normal sync with no forced upload or download.

Both timestamps compare as the same second. syncFile() returns without reading the remote content, so the different contents are treated as synchronized.

Dropbox and WebDAV currently use second precision.

Expected Behavior

If local and remote contents differ, sync should not silently treat them as synchronized solely because their timestamps are indistinguishable at the backend's precision.

The existing last-write-wins design can remain; the expected behavior for a timestamp tie can be decided separately.

Actual Behavior

When the timestamps compare equal at backend precision, syncFile() returns null without comparing content.

The sync can therefore complete without establishing whether the local and remote versions are actually identical.

Browser

Not browser-specific; this is in the shared sync backend logic.

uBlacklist Version

Current master / 10.0.3-era sync implementation

Search Engine

None

Additional Context

Relevant code:

src/scripts/background/sync-backends.ts
src/scripts/sync-backends/dropbox.ts
src/scripts/sync-backends/webdav.ts

This is separate from the initial-sync conflict handled in #515. That issue defines which side should win when initially enabling sync. This case concerns two revisions that normal last-write-wins cannot order because the backend exposes both timestamps at the same precision.

Checklist

• I have searched existing discussions and issues to ensure this bug hasn't been reported before
• I have tried disabling other extensions to isolate the issue