v1.2.4

Fix false-conflict duplicate notes still forking on ordinary edits

The 1.2.1 fix only avoided a spurious "(conflict)" fork when the local edit
was metadata-only - it compared the server's content against the pending
local edit, which differs from the server whenever there's a real text edit
queued, conflict or not. So an ordinary edit that hit a non-conflicting 412
(e.g. a server-side etag bump unrelated to content) still forked a
duplicate. NoteEntity now tracks syncedContent, the content last confirmed
from the server and untouched by local edits, so a 412 is checked against
that baseline instead of the in-flight edit. Adds a Room migration for the
new column, and stops a failed conflict-GET from clearing the dirty flag
(which could silently drop the pending edit).

Verified on-device: a stale-etag/no-real-change 412 now heals with no fork
and the edit lands on the next sync; a genuine concurrent edit still forks
correctly; an in-place upgrade from the old schema with a dirty unsynced
note survives the migration intact.

Co-Authored-By: Claude <noreply@anthropic.com>