Say what a timestamp tie actually does to the toggle

The tie test claimed the local record only repeated the server value, but
it fixtures opposing toggles stamped at the same instant, so name it for
the rule it proves. Note beside the strategy why that tie needs no
deterministic tiebreaker: no writer stamps these settings with a fixed
epoch date, unlike accounts and data contexts.

Yattee/Services/CloudKit/CloudKitConflictResolver.swift

@@ -341,6 +341,10 @@ actor CloudKitConflictResolver {
     /// - Last write wins based on updatedAt timestamp — the same rule
     ///   `DataManager.upsertChannelNotificationSettings` applies on arrival, so a
     ///   record that wins the upload is never refused by the other device.
+    /// - An exact tie keeps the server value and needs no deterministic
+    ///   tiebreaker: unlike accounts and data contexts, no writer stamps these
+    ///   settings with a fixed epoch date, so a tie is an accident of the clock
+    ///   rather than something migration produces on every device.
     /// - Preserve server recordChangeTag
     func resolveChannelNotificationSettingsConflict(
         local: CKRecord,

YatteeTests/CloudKitSyncTests.swift

@@ -197,7 +197,7 @@ struct CloudKitSyncTests {
             #expect(resolved["updatedAt"] as? Date == Date(timeIntervalSince1970: 2_000))
         }
 
-        @Test("A local record that only repeats the server value leaves it untouched")
+        @Test("Equal timestamps keep the server value")
         @MainActor
         func equalTimestampsKeepServerValue() async throws {
             let mapper = CloudKitSyncTests.makeMapper()