feat(backup): include the trash in exports and auto-backups

A backup that silently drops the trash is not a backup: export, empty the vault, import, and the trashed entries were gone for good with nothing said. Both containers now carry state.trashed with deleted/deleted_at, and deleted_at is preserved so a restore resumes the auto-purge clock instead of restarting it - hence its addition to the GET echo.

The sync snapshot deliberately does NOT: the trash is device-local, and re-publishing deleted rows is what produced the duplicate-uuid bug. The two identical export loops were folded into buildBackupEntry first, so the trash handling exists once.

CLAUDE.md

@@ -496,6 +496,17 @@ retirée** (site='' quand chiffré) — le client la fait. `folder` reste en cla
 (requête serveur de réassignation sur delete-folder). Reste en clair :
 `folder`, `kind`, métadonnées d'attachments, nombre de lignes, timestamps.
 
+**La corbeille voyage dans les sauvegardes, pas dans la sync** (2026-08-03) :
+`buildBackupEntry` (js/app.import.js) est le point unique qui met en forme une
+entrée pour un conteneur — partagé par l'export manuel **et** l'auto-backup, qui
+en portaient deux copies. Les deux exportent `state.entries` **+**
+`state.trashed`, avec `deleted` / `deleted_at` ; `deleted_at` est préservé pour
+que l'auto-purge reprenne où elle en était au lieu de repartir à zéro (d'où son
+ajout à l'écho de `GET /entries`). `buildSyncSnapshot` **n'utilise pas** ce
+helper et n'envoie que le vivant : la corbeille est device-local, et republier
+des lignes supprimées les dupliquerait (cf. le bug F8 où 30 entrées mises à la
+corbeille revenaient vivantes, deux lignes pour un même uuid).
+
 Quand tu ajoutes un nouveau champ (chiffré ou non), il faut **toujours**
 mettre à jour ces 6 endroits sous peine de perdre la donnée silencieusement
 sur certaines actions :