Come back from a sync position the server will not accept

"The server returned 400: The sync cursor is not valid for this vault. Resync
from the beginning." told the user exactly what to do and gave them no way to
do it. The cursor is the only thing a pull sends, so the refusal was permanent:
the next pass read the same stored cursor and was told the same thing, once a
minute, for ever. And because the pull runs first, the exception ended the pass
before it reached the outbox — so the vault stopped receiving other machines'
changes and stopped sending its own. A machine that met this went quietly
read-only until somebody deleted its cache.

The engine now does what the message asks. A pull refused with the
invalid-cursor problem code — the code, never the prose, which is free to
change — drops this vault's position, writes that down, and reads the log again
from the beginning. The restarted request carries no cursor, which is the one
position a server cannot reject, so the retry cannot loop; a refusal of that is
rethrown rather than retried, and a restart is allowed once per pull. The
position is saved before the replay starts, so a process that dies halfway
through begins the next one from the beginning too rather than meeting the same
refusal again.

The mirror is deliberately kept. Replaying rewrites every row the server still
has and applying a change is a blind overwrite, so the re-pull repairs the
mirror on its way past; clearing it first would claim more than the evidence
supports — the position was refused, not the contents — and would leave a
machine that lost its connection mid-replay with less than it started with.
That leaves one gap, named in the remarks rather than left to be discovered:
once tombstone collection exists, a replay stops carrying deletions older than
the retention window.

None of the causes are the user's doing — a rotated cursor signing key, a vault
served from a restored database, a cache copied between machines — so nothing
asks them to decide anything. The report carries ResyncedFromStart and the
status line says the position was not recognised and the vault was read again.
It is kept out of NeedsAttention, because nothing is outstanding, but the
background pass breaks its usual silence for it: a sync that pulled the whole
vault on a day nobody changed anything otherwise reads as a fault.

The fake server grew a switch that refuses cursors the way a rotated signing
key does, including ones it minted itself. Three cases: the vault is re-read
and the change on the far side of the refused position arrives; the edits
waiting in the outbox are still pushed in that same pass, which is the half
that made this worth recovering from rather than merely reporting; and a server
that refuses the beginning itself is surfaced instead of replayed against.

dotnet build is clean at zero warnings, dotnet format is clean, and the sync
and app suites pass — 109 and 101.

src/DodoSSH.Client.App/ViewModels/VaultViewModel.cs

@@ -1276,7 +1276,12 @@ internal sealed partial class VaultViewModel(
 
             var report = await SyncOnceAsync(server.Sync, cancellationToken).ConfigureAwait(true);
 
-            if (report is not null && (report.Pulled > 0 || report.Pushed > 0 || report.NeedsAttention))
+            // A pass that had to start over says so even when it pulled nothing, which is the one place
+            // this loop breaks its own rule about staying quiet. A machine that silently re-read the whole
+            // vault has had something happen to it, and the alternative is that nobody ever finds out.
+            if (report is not null
+                && (report.Pulled > 0 || report.Pushed > 0 || report.NeedsAttention
+                    || report.ResyncedFromStart))
             {
                 Status = Describe(report);
             }
@@ -2493,11 +2498,19 @@ internal sealed partial class VaultViewModel(
     /// </remarks>
     private static string Describe(SyncReport report)
     {
+        // Said first, and in both branches, because it is the explanation for the numbers after it. A pass
+        // reporting "214 in" on a vault nobody has touched all week reads as something having gone wrong;
+        // this is what actually happened, and it needs nothing from the reader.
+        var replayed = report.ResyncedFromStart
+            ? "The server no longer recognised this machine's position, so the vault was read again from "
+                + "the beginning. "
+            : string.Empty;
+
         if (!report.NeedsAttention)
         {
-            return report.Pulled == 0 && report.Pushed == 0
+            return replayed + (report.Pulled == 0 && report.Pushed == 0
                 ? "Already up to date."
-                : $"Synchronised: {report.Pulled} in, {report.Pushed} out.";
+                : $"Synchronised: {report.Pulled} in, {report.Pushed} out.");
         }
 
         var notes = new List<string>();
@@ -2529,7 +2542,7 @@ internal sealed partial class VaultViewModel(
             notes.Add("this vault was rekeyed and your access needs re-issuing");
         }
 
-        return "Synchronised, but: " + string.Join("; ", notes) + ".";
+        return replayed + "Synchronised, but: " + string.Join("; ", notes) + ".";
     }
 
     private async Task RunAsync(string busyMessage, Func<Task> work)