Chat sync: tombstones to stop resurrecting conversations deleted on another device

Follow-up from PR #1067 (CodeRabbit review of `unifiedHistoryStorage.ts`).

## Problem
`runSync()` treats every local-only chat as an unsynced migration candidate and pushes it to the backend. If a conversation was deleted on another device, stale IndexedDB data on this device recreates it on the next sync.

## Proposed direction
Track deletion tombstones / per-conversation sync state so a local-only record that represents a remotely-deleted conversation is not re-pushed. Distinguish "never synced (migrate)" from "synced then deleted elsewhere (drop)".

## Why deferred
Requires a sync-state/tombstone model across IndexedDB and backend — a design feature beyond PR #1067's scope. Split out to design deliberately.

Related: deletion is now mirrored to the backend on the delete paths in #1067, but that does not by itself prevent resurrection from stale local-only records, which is what this issue covers.

Start by reading PR #1067 and unifiedHistoryStorage.ts, especially runSync() and the delete paths it changed. Map how IndexedDB records are distinguished from backend-synced records before proposing a sync-state or tombstone model. Done means stale records for conversations deleted elsewhere are not re-pushed, while never-synced conversations still migrate.

Written by the indexing model from the issue text.