fix(sync): re-pull from zero before pushing after a refused cursor, and drop purged deletes

[kYem]

Fixes ENG-127

• After a refused cursor, runCycle re-pulls from since=0 before pushing. If that is refused too, the push still runs, since compare-and-set keeps it off newer rows.
• The server now says why it refused:
  • resync_required (the cursor is behind the purge watermark): the client deletes the synced entities its full listing no longer finds (dropPurged).
  • new cursor_ahead (the cursor is past last_seq, so the database was restored): the client re-pushes what the restore lost (repushLost).
  • A row merely missing from a pull from zero deletes nothing.
• GET /v1/changes also:
  • serves later pages of a listing from 0 (listing=full) past the watermark, so accounts over 500 rows can finish a full listing;
  • raises a final page's cursor to the watermark, so the next pull isn't refused again.
• A same-account re-auth keeps its cursor and seqs, so the server can refuse a stale cursor.

Deploy the API before releasing the clients. A client on the old server keeps its cursor on re-auth but gets no restore detection.

Known limits:

• Restore detection is partial; ENG-152 tracks a reliable version.
• An edit racing a purge delete across extension realms can be lost. It is logged at error, the same race pulled tombstones have.
• The client's PULL_PAGE and the server's page size must stay equal.