Implements the Delete half of #268 (the design settled there; the recording-axis as-of in 0019 stays planned).

Before: DELETE FROM documents cascaded chunks and fact_evidence away. Facts stayed live in the graph with no provenance — the opposite of what the privacy policy promised — and a synced document deleted locally came back on the next sync as a new row, re-asserting its facts on top of the old ones.

Now: deleting is an event on the recording axis.

• documents.deleted_at tombstone; chunks take superseded_at; nothing is cleared (text, embedding, blob all stay until an explicit purge — follow-up PR).
• Only facts whose every source is deleted are retired. A fact another live document vouches for keeps it. The rule reads documents.deleted_at, not the chunk's superseded_at: evidence stuck on an old version is stale, not sourceless.
• document_deletions records which facts and chunks this deletion touched, shaped like entity_merges; restore revives exactly that list, so a fact retired before the deletion is not accidentally saved.
• Three ways back through one store function: the Undo on the toast (POST /documents/{id}/restore), sync meeting a tombstone whose source still has the file, and re-uploading the same content (it would otherwise hit the (kb_id, sha256) unique index).
• Every documents read filters deleted_at IS NULL (library, page, counts, dedupe, extraction queue, retrieval candidates); the evidence panel says "source deleted" on a quote whose document is gone.
• Delete and restore both re-settle derivations when the base materializes inferences.

Wording in the privacy policy and the cleanup dialog now says what actually happens.

Test: a_deletion_is_an_event (store, DB). Verified end to end in the isolated env: delete → toast "1 fact retired" with Undo → evidence reports document_deleted → Undo → restored, audit trail document.deleted / document.restored, ledger rows reverted.

Closes #268

🤖 Generated with Claude Code