fix(persistence): order the sync outbox by a monotonic sequence, not by a timestamp

[Adron]

Summary

Closes #84.

The outbox is a FIFO whose entire contract is replay these changes in the order they happened, and it was ordered by enqueuedAt alone — a non-total key. Two entries stamped in the same instant tie, SortDescriptor specifies no tiebreak, and their relative order was whatever the store returned.

For a document-sync queue that is a data-shaped failure: an .updateDocument replayed before the .createDocument it depends on, or a .deleteFolder overtaking the .renameFolder ahead of it. Silent, and with no stack trace.

The tests already knew

try await store.enqueueOutbox(.deleteDocument(id: "first"))
// SwiftData uses Date() at enqueue — sleep briefly so timestamps differ.
try await Task.sleep(nanoseconds: 5_000_000)

Five sleeps across two files whose only job was to keep the production sort key total. A test that has to slow the system down to make its assertion true is describing a defect in the system.

All five are deleted, and enqueuing back to back with no delay is now the regression test — including a 50-entry tight loop, which timestamp resolution cannot be relied on to separate.

Design notes

max(sequence) + 1, read from the store — not a process-local counter. A counter restarts at zero on the next launch and interleaves new entries among old ones. There is an on-disk reopen test for this, because an in-memory container is created fresh every time and can never exercise a migration.

From the max, not the row count. Dequeuing removes rows, so a count-based sequence would reissue a position already held by an entry still waiting behind it — putting the tie right back. There is a test that dequeues from the middle and then enqueues more.

Additive with a default, so SwiftData's lightweight migration opens an existing store. Rows written before it arrive as 0 and sort ahead of everything new, which is correct — they are older. Their order relative to each other is whatever it already was; this cannot retroactively recover an order that was never recorded, and the comment says so rather than implying it can.

enqueuedAt stays, documented as the human-facing timestamp it is rather than the sort key it was being used as.

Also

The last fixed sleep in DocumentSyncEngineTests (a flat 50 ms wait for an event collector) is converted to post-condition polling — the same lesson as #82. The persistence suite now has no wall-clock waits at all.

Verification

• xcodebuild build → ** BUILD SUCCEEDED **
• xcodebuild test (App) → Executed 968 tests, with 0 failures · ** TEST SUCCEEDED **
• swift test InterlinedPersistence → Executed 147 tests, with 0 failures (was 140)
• swift test InterlinedDomain → Executed 1012 tests, with 0 failures
• swift test InterlinedKit --skip ContractTests → Executed 477 tests, with 0 failures
• Decision 0003 (anchored) → zero hits

New tests (7): same-instant ordering at 50 entries · strictly-increasing sequences · dequeue-from-the-middle · fully-drained-then-refilled · a failed push keeping its place · create-then-update dependency order · on-disk reopen continuing the sequence.

Note

Includes a merge of #99 (fix/xcode27-document-ambiguity), without which the App target does not build on Xcode 27. Merge #99 first and this reduces to the persistence change alone.

🤖 Generated with Claude Code