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.Sync/SyncReport.cs

@@ -75,6 +75,15 @@ public sealed record SyncOptions
 /// True when the push loop hit <see cref="SyncOptions.MaxPushRounds"/> with work still outstanding. Not
 /// a failure: the next pass continues from here.
 /// </param>
+/// <param name="ResyncedFromStart">
+/// True when the server refused this machine's stored position and the whole log was read again from the
+/// beginning.
+/// <para>
+/// Deliberately absent from <see cref="NeedsAttention"/>. Nothing is outstanding and nothing was lost —
+/// the pass recovered on its own — but it explains a sync that pulled the entire vault on a day nobody
+/// changed anything, which is otherwise the sort of thing that looks like a fault.
+/// </para>
+/// </param>
 public sealed record SyncReport(
     Guid VaultId,
     int Pulled,
@@ -87,7 +96,8 @@ public sealed record SyncReport(
     uint ServerKeyGeneration,
     bool RekeyRequired,
     long ServerTimeSkewMs,
-    bool RoundsExhausted)
+    bool RoundsExhausted,
+    bool ResyncedFromStart)
 {
     /// <summary>Whether anything happened that a user should be told about.</summary>
     public bool NeedsAttention =>
@@ -119,6 +129,8 @@ internal sealed class SyncReportBuilder(Guid vaultId)
 
     internal bool RoundsExhausted { get; set; }
 
+    internal bool ResyncedFromStart { get; set; }
+
     internal SyncReport Build() =>
         new(
             vaultId,
@@ -132,7 +144,8 @@ internal sealed class SyncReportBuilder(Guid vaultId)
             ServerKeyGeneration,
             RekeyRequired,
             ServerTimeSkewMs,
-            RoundsExhausted);
+            RoundsExhausted,
+            ResyncedFromStart);
 }
 
 /// <summary>The record written to the conflict log when a merge had to override something.</summary>