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/SyncEngine.cs

@@ -129,12 +129,30 @@ public sealed class SyncEngine
     {
         var state = await syncState.ReadAsync(vaultId, cancellationToken).ConfigureAwait(false);
 
+        // At most one restart per pull. A server that rejects the cursor it has just issued is not
+        // telling this client anything it can act on, and replaying the whole log against it would turn
+        // one broken deployment into an unbounded amount of work.
+        var alreadyStartedOver = false;
+
         for (var page = 0; page < options.MaxPullPages; page++)
         {
-            var response = await api.SyncPullAsync(
-                vaultId,
-                new SyncPullRequest(state.Cursor, options.PullPageSize, ItemKinds.SyncedTypes),
-                cancellationToken).ConfigureAwait(false);
+            SyncPullResponse response;
+
+            try
+            {
+                response = await api.SyncPullAsync(
+                    vaultId,
+                    new SyncPullRequest(state.Cursor, options.PullPageSize, ItemKinds.SyncedTypes),
+                    cancellationToken).ConfigureAwait(false);
+            }
+            catch (DodoSshApiException exception)
+                when (!alreadyStartedOver && WasTheCursorRefused(exception, state.Cursor))
+            {
+                alreadyStartedOver = true;
+                state = await StartOverAsync(state, report, cancellationToken).ConfigureAwait(false);
+
+                continue;
+            }
 
             foreach (var change in response.Changes)
             {
@@ -161,6 +179,69 @@ public sealed class SyncEngine
         }
     }
 
+    /// <summary>
+    /// Whether the server refused the cursor this client sent, rather than failing for some other reason.
+    /// </summary>
+    /// <remarks>
+    /// Read from the problem code and not from the prose, which is free to change, and never claimed for a
+    /// request that carried no cursor: "from the beginning" is the one position a client is allowed to ask
+    /// for, so a rejection of <em>that</em> is a server this code cannot reason about and has to surface.
+    /// It is also what keeps the retry from looping — the restarted request sends no cursor.
+    /// </remarks>
+    private static bool WasTheCursorRefused(DodoSshApiException exception, string? cursor) =>
+        !string.IsNullOrEmpty(cursor)
+        && string.Equals(exception.Code, ProblemCodes.InvalidCursor, StringComparison.Ordinal);
+
+    /// <summary>
+    /// Forgets this vault's position and reads the log again from the beginning.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// A cursor the server will not accept is not a transient failure. Every later pass reads the same
+    /// stored cursor and is refused the same way, so a vault that met one stayed there for good — pulling
+    /// nothing, and pushing nothing either, because the pass threw before it reached the outbox. The user
+    /// saw a 400 saying to resync from the beginning and had no way to do it. This is that way.
+    /// </para>
+    /// <para>
+    /// The causes are all on the far side: a rotated cursor signing key, a vault served from a restored
+    /// database whose sequences no longer reach that far, a cache copied between machines. None of them is
+    /// something the person at the keyboard did, and none of them is something they could act on if asked.
+    /// </para>
+    /// <para>
+    /// <b>The mirror is deliberately kept.</b> Replaying from the beginning rewrites every row the server
+    /// still has — applying a change is a blind overwrite — so the re-pull repairs the mirror as it goes.
+    /// Clearing it first would claim more than the evidence supports: the position was refused, not the
+    /// contents, and a machine that loses its connection halfway through the replay would be left with
+    /// less than it started with. <c>SyncStateStore.ResetAsync</c> is the heavier remedy, for when the
+    /// cache itself is the thing in doubt.
+    /// </para>
+    /// <para>
+    /// That leaves one gap, and it is worth naming rather than leaving to be discovered: once the server
+    /// starts collecting tombstones — <c>DodoOptions.TombstoneRetentionDays</c>, not implemented yet — a
+    /// replay no longer carries a deletion older than the retention window. A machine that missed such a
+    /// delete and then had its cursor refused would keep the row. Nothing here can tell that from a row
+    /// the server still has, so the answer when it matters will be to clear the mirror as well, not to
+    /// guess.
+    /// </para>
+    /// <para>
+    /// Written down before the replay begins, so a process that dies mid-replay starts the next one from
+    /// the beginning as well, rather than meeting the same refusal again.
+    /// </para>
+    /// </remarks>
+    private async Task<StoredSyncState> StartOverAsync(
+        StoredSyncState state,
+        SyncReportBuilder report,
+        CancellationToken cancellationToken)
+    {
+        var restarted = state with { Cursor = null };
+
+        await syncState.SaveAsync(restarted, cancellationToken).ConfigureAwait(false);
+
+        report.ResyncedFromStart = true;
+
+        return restarted;
+    }
+
     private StoredSyncState Record(
         Guid vaultId,
         StoredSyncState state,