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/admin/data/route.ts

@@ -113,7 +113,11 @@ export const DELETE = apiHandler(async (request: NextRequest) => {
 
       // Every account row survives; the personal data carried on its own
       // columns does not. Same classification contract as the model list.
-      await tx.user.updateMany({ data: USER_RESET });
+      // Paired clients drop their delta cursors and start over, instead of
+      // catching up from a position whose rows are gone (`syncResetAt`).
+      await tx.user.updateMany({
+        data: { ...USER_RESET, syncResetAt: new Date() },
+      });
 
       return perModel;
     },