docs(api): deleted-annotation history + KOReader deletion propagation

New media-items/deleted_annotations.md for the list/restore/purge
endpoints; endpoint index updated. The KOReader protocol page documents
deleted_highlights/deleted_bookmarks on the progress push and the
deletion-propagation contract: keys learned only from server pulls,
explicit arrays only (never absence), tombstone convergence via the
metadata fetch, no resurrection from stale replays, and the web history
as the restore path.

docs/developer/api/sync/koreader-protocol.md

@@ -33,6 +33,8 @@ KOReader uses a custom JSON-based sync protocol.
 | books[].epubcfi    | string  | No       | EPUB CFI location                                    |
 | books[].character  | integer | No       | Character offset                                     |
 | books[].bookmarks  | array   | No       | Array of bookmarks/highlights (shape, color mapping, and echo/dedup rules: see [Sync Bookmarks](../koreader/sync_bookmarks.md)) |
+| books[].deleted_highlights | array | No | Highlights deleted on the device: `[{ "dedup_key": "..." }]` — keys previously served to this device (see [Deletion propagation](#deletion-propagation)) |
+| books[].deleted_bookmarks  | array | No | Bookmarks deleted on the device: `[{ "dedup_key": "..." }]` |
 
 \* At least one of `uuid` or `sha256` should be present. The server resolves the
 book through the shared `BookResolver` with this priority: `uuid` → `sha256` →
@@ -170,6 +172,32 @@ returned so clients can cache it regardless of how the book was originally
 obtained. The library list endpoint (`GET /api/sync/koreader/library`) includes
 the same `sha256` field on each book.
 
+## Deletion propagation
+
+The progress push is upsert-only: absence of an annotation from
+`highlights`/`notes`/`bookmarks` is **never** interpreted as a delete (a
+client with a category disabled must not wipe the server). Deletions are
+reported explicitly:
+
+- Devices remember the `dedup_key` of every annotation the server served
+  them (persisted locally, e.g. KOReader's sidecar `bookhoard_known_keys`).
+- When one of those annotations no longer exists locally, the next push
+  lists its key in `deleted_highlights` / `deleted_bookmarks`.
+- The server tombstones the matching rows (`deleted = TRUE`, kept for the
+  retention window). Tombstones are served back to *other* devices via the
+  metadata fetch's `deleted_highlights` / `deleted_bookmarks` arrays so the
+  deletion converges everywhere.
+- A stale replay pushing the annotation's content cannot resurrect the
+  tombstone: device pushes carry no modification timestamp, so the save is
+  treated as older than the delete.
+- Restoring is possible from the web book page's deleted-annotation
+  history (`GET /api/media-items/:id/annotations/deleted`, restore/purge
+  endpoints) until the retention window lapses.
+
+Because keys are only learned from server pulls, a device-native annotation
+deleted locally is simply never pushed again — it can never be mis-flagged
+as a server annotation deletion.
+
 ## Book identification
 
 Every client/sync interface (KOReader, Kobo, OPDS, the device-link UI, and any