fix: serialise the wear queue drain process-wide, stop sync cancelling itself

[SiteRelEnby]

Reliability follow-up to the security PR. Two offline-switch duplication windows, both confirmed.

Wear: the queue-drain lock was per-instance

WearStore.queueDrainMutex was a plain instance field. But three sites each construct their own WearStore
over the same SharedPreferences-backed queue:

• MainActivity
• WearDataLayerService (phone nudge -> refresh)
• QuickSwitchTrampolineActivity

So the mutex only serialised drains within one instance. Two instances could each snapshot the queue, and
each call createFront for the same row before either removed it -> the front is created twice. This is the
same bug shape that WearApiClient.refreshMutex was hoisted to a companion object to fix; queueDrainMutex
just never got the same treatment. Now it lives in WearStores companion object, shared process-wide.

Phone: REPLACE could cancel a drain mid-createFront

SyncWorker.schedule used ExistingWorkPolicy.REPLACE. The drain posts createFront before deleting the
queue row (the create-before-delete window the code already documents), so a REPLACE that cancels a
running drain right then can leave the front created on the server with the row still queued -> replayed and
duplicated on the next run.

Switched to KEEP: an enqueue while a drain is in flight is dropped instead of cancelling it. Rows added
after the running drain snapshotted the queue are picked up by the next schedule() call, and every offline
action plus every reconnect calls it, so the tail latency is small. This trades a little latency for not
double-creating fronts. True exactly-once still needs a server-side Idempotency-Key on createFront
(already flagged in doWork); this closes the client-side half.

Not fixed here

The phone handoff from the watch still trusts the BLE send-Task with no application-level ack and no uuid
dedup on the phone. That is a protocol change (the phone would need to dedup on the switch uuid it already
receives but currently drops) and is worth its own PR.

Verification

• :app:assemblePlayRelease :wear:assembleRelease :app:testPlayReleaseUnitTest :wear:testPlayReleaseUnitTest green.
• Hard to unit-test meaningfully (both are concurrency/WorkManager-scheduling behaviour); worth a device
  check by making rapid offline switches on the watch and on the phone and confirming no duplicate fronts
  after reconnect.