Report Process Conversation Deletions

A process reporting conversations the user deleted on ITS OWN disk, so the cloud hides the archived copies (cloud_sync_conversations's deletion push).

The cloud cannot work this out for itself: conversation sync is push-only, so a deleted conversation merely stops being pushed — indistinguishable from an idle one. Its archive row therefore stayed deleted_at='' forever and resurfaced on the user's other devices every time this process went offline and the list fell back to the cache.

Distinct from DELETE .../conversations/{session_id} on purpose. That route is for a conversation living on some OTHER process and relays the delete to its owner. Here the owner is the caller and the files are already gone, so there is nothing to relay — and relaying would bounce the delete straight back into the caller's own store, which re-logs it and re-reports it on every sweep.

Idempotent: re-reporting an id already stamped marks nothing (the UPDATE is guarded on deleted_at=''), and an id the cloud never saw marks nothing either. Both are fine — the caller clears its log on 200 either way.