Conversations this user deleted, for the owning core's sync sweep to reap from its local store (cloud_sync_conversations::sweep_once).

Deliberately scoped to the USER, not to process_id — a conversation exists in several stores at once (the local shell + the owning process's real copy), and "the user deleted S" is true for every machine holding S. process_id is here for auth and to keep the route next to its siblings.

since is the caller's cursor (the cursor from its last pull): only tombstones sequenced after it are returned, so a daemon that has been off for a month gets exactly what it missed and a busy one re-pulls nothing. Reaping is idempotent, so a cursor lost to a crash costs one redundant (no-op) delete, never a missed one.

Grouped by session_id because one conversation has a row per process that ever synced it, each with its own seq — the puller wants one tombstone per conversation, carrying the newest seq so the cursor clears them all.