fix(sync): expire delta cursors issued before a restore or a data wipe

A restore writes rows back with their original updatedAt, behind every
paired client's watermarks, and removes rows without leaving tombstones.
A client that kept its cursor would miss both on its next incremental
pull. The same holds after the person deletes all their data.

`users.sync_reset_at` (migration 0363) records when the record was last
replaced: the restore stamps it as its last write and again right after
the commit, the per-account and the admin wipe stamp it inside their
transactions. Cursors now carry the time they were issued, and
/api/sync/changes answers its existing `cursorExpired` to a cursor issued
before the reset, or one without an issue time on an account that has
one. The comparison is on the issue time, because after a restore a
freshly drained cursor still carries old watermarks.

src/app/api/settings/data/route.ts

@@ -23,6 +23,7 @@ import {
   wipeDelegateKey,
   WIPE_MODELS,
 } from "@/lib/data-wipe/wipe-plan";
+import { stampSyncReset } from "@/lib/sync/reset";
 
 export const dynamic = "force-dynamic";
 
@@ -104,6 +105,9 @@ export const DELETE = apiHandler(async (request: NextRequest) => {
         // The account row survives; the personal data carried on its own columns
         // does not. Same classification contract as the model list.
         await tx.user.update({ where: { id: userId }, data: USER_RESET });
+        // Paired clients drop their delta cursors and start over, instead of
+        // catching up from a position whose rows are gone.
+        await stampSyncReset(tx, userId);
 
         // The nightly off-host copies of the record are part of "all your
         // data". The request commits with the wipe; the purge job deletes