feat(sync): a stable identity per contact, indexed

Two PCs exchanging changes through a folder must be able to name the SAME
contact in both logs. "the QSO with M0ABC at 14:32" is a guess and the two
machines can disagree about which row that is, so an edit or a deletion cannot
be addressed at all without an identity that travels with the record.

A real indexed column, not a key inside extras_json: the identity is resolved
once per incoming change, and scanning JSON for it would turn every sync into a
full read of a 120 000-QSO logbook. A column costs one migration; the JSON would
cost a scan every time. That was the decision to confirm, and it is confirmed.

It follows the award_refs pattern — read in selectCols, absent from columnList,
written only through its own methods. So an ordinary edit cannot clobber it,
which matters: another machine addresses the contact by that id, and losing it
makes the same QSO arrive again as a new one. Pinned by a test that saves an
edit with the field deliberately blanked.

Existing contacts are stamped in batches inside one transaction rather than one
commit each — on a remote MySQL the round trip dominates, and 120 000 commits is
the difference between a minute and an afternoon. And a dedupe-key map lets two
machines that already hold the same imported log recognise each other's contacts
instead of copying 120 000 of them across.

MySQL nearly lost its logbook to this. It cannot index a TEXT column without a
prefix length: the migration would fail with error 1170 and fail again on every
startup, with no way out from the interface. The translator only emits VARCHAR
for names listed by hand in varcharColumns. sync_uid is now listed — and a test
reads the migrations, works out which indexed columns are TEXT, and fails if the
list does not cover them, so the next one cannot reach a shared logbook.

internal/db/migrations/0029_sync_uid.sql

@@ -0,0 +1,20 @@
+-- A stable identity per contact, for folder-based synchronisation.
+--
+-- Two PCs exchanging changes through a shared folder need to name the SAME
+-- contact in both logs. "the QSO with M0ABC at 14:32" is a guess, and the two
+-- machines can disagree about which row that is — so an edit or a deletion
+-- cannot be addressed at all without an identity that travels with the record.
+--
+-- A REAL COLUMN, indexed, rather than a key inside extras_json. The identity is
+-- looked up once per incoming change, and on a 120 000-QSO logbook scanning
+-- JSON for it would turn every sync into a full table read. A column costs one
+-- migration; the JSON would cost a scan every time.
+--
+-- sync_uid is listed in varcharColumns (internal/db/mysql.go): MySQL cannot
+-- index a TEXT column without a prefix length, and a migration that tries dies
+-- with error 1170 on every startup thereafter, with no way out from the UI.
+--
+-- Empty on every existing row: they are given an identity the first time
+-- synchronisation is switched on, in one bulk statement, not row by row.
+ALTER TABLE qso ADD COLUMN sync_uid TEXT NOT NULL DEFAULT '';
+CREATE INDEX IF NOT EXISTS idx_qso_sync_uid ON qso (sync_uid);