fix(server-storage): a restore merged by a conflict stays parked; first-read tests wait for the read

A restore whose write conflicted with an edit another device made during
it had the conflict replay merge that edit in, and flushed() still said
the lists were taken, so the restore was consumed with lists that were
not the backup's. Both restore paths now compare the stored lists with
the ones they wrote once the server took them, and a difference keeps
the restore parked to run again on a fresh read.

The two first-read tests released the mocked read after a fixed number
of microtask turns, which could come before the read started; they now
wait until it has.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/pwa-self-hosted.md

@@ -273,8 +273,9 @@ settings and guards read them in every build.
   would merge into the server's instead of replacing them (the restore
   stays parked). A restore also replaces nothing while this page's own
   writes for the playlist are unsent (they would join the replacement) and
-  counts only once the server took its lists (`UserDataStorage.flushed`);
-  either way it stays parked. Replayed edits keep recently viewed lists newest first,
+  counts only once the server took its lists (`UserDataStorage.flushed`)
+  as they are: a conflict that merged another device's edit in leaves it
+  parked to run again on a fresh read. Replayed edits keep recently viewed lists newest first,
   as the app cuts them at their limit from the end. Also,
   re-reads run one at a time and keep entries edited while they were in
   flight or not yet saved, and entries another tab saved meanwhile or had