sync_chapters_serializes_concurrent_calls_for_same_manga asserted a single
ordering ([A,B,C]) that the per-manga advisory lock cannot guarantee: it
serializes the two concurrent syncs but not WHICH wins the lock last. Under
heavy CI load the order inverted — call X (list [A,B]) committed last and
correctly soft-dropped C (a key it never saw), yielding [A,B] → assertion
failed. Both [A,B,C] (Y last) and [A,B] (X last) are valid last-writer-wins
serializations; the lock only guarantees no TORN state. Accept either.
Pre-existing flake (test unchanged since 0.52.0, lock since 0.55.0); product
sync logic is correct and untouched. Unblocks the 0.84.0 deploy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
