Let an incoming context settle what a repair cannot argue with

A repair is a fallback, not a choice: it borrows the timestamp of the
selection it replaced so that a later choice still beats it, and it is
never published. But that borrowed rank also won arguments it had no
business winning. An incoming explicit context stamped at the same instant
that loses the `DataContext.tieBreakKey` tie was neither adopted — the
repair was not outranked — nor pushed back, because a repair pushes
nothing. Neither side moved, and the fallback stood against the server's
explicit value indefinitely. The tie is not theoretical: migrated contexts
are all stamped at the epoch, and a repair keeps the timestamp of whatever
it replaced, so two migrated-era values meet as equals.

A stored repair now never outranks an incoming context — it is replaced by
whatever arrived, older or tied, and nothing is ever enqueued for that.
Adopting is safe whatever the incoming value names: one naming an account a
tombstone dominates has already been turned back into a repair before the
comparison, so it stays unpublished and lands on the same target this
device's repair did.

Two more from the same trace:

- Staged records are applied by category, and contexts already come last so
  that a repair reads the accounts and the instance a dominated record left
  behind rather than falling to local past a signed-in sibling. That
  ordering was load-bearing and unremarked; it is now written down, along
  with what it does not cover — a context applied in an earlier batch than
  the account record that says where the deleted account lived still
  repairs without it, which the next explicit choice anywhere settles.

- An install that repaired its context before the repair bit existed reads
  back as having chosen it, so that one repair can still be published once.
  Accepted and documented at the load site: no shipped release ever
  persisted a data context, the window is interim builds only, and the next
  explicit choice heals it.

Yattee/Services/CloudKit/AccountSyncCoordinator.swift

@@ -410,9 +410,24 @@ final class AccountSyncCoordinator {
         isApplyingStagedChanges = true
         defer { isApplyingStagedChanges = false }
 
-        // Tombstone-first. A deletion that arrived in a later event than the
+        // Applied by category rather than in the order the records happened to
+        // be fetched, because each category depends on the ones before it.
+        //
+        // Tombstone-first: a deletion that arrived in a later event than the
         // account record it kills must still be applied before it, or the
         // account becomes visible — and selectable — in between.
+        //
+        // Contexts last: repairing a context naming a deleted account reads the
+        // accounts and the instance a dominated record left behind, and a repair
+        // evaluated before that state exists lands on local past a signed-in
+        // sibling on the same server, with nothing to re-run it afterwards.
+        //
+        // Only within a batch, which is what a fetch delivers and what a
+        // deferred activation accumulates. A context applied in an *earlier*
+        // batch than the account record that says where the deleted account
+        // lived still repairs without it; the next explicit choice anywhere
+        // settles that, and re-repairing on every later record would undo
+        // choices made in between.
         let tombstones = staged.filter { change in
             switch AccountRecordName.parse(change.recordName) {
             case .accountDeletion: return change.kind == .save