docs(android): the phone cannot remove an attachment, and patching would not hold

Worth recording before someone tries. The desktop restores attachments only
for a NEW entry; for an entry it already knows, the merge leaves them alone.
Publishing a snapshot without the attachment would leave the row untouched in
its database, and its next buildSyncSnapshot would put it back - the removal
would undo itself on the following pull.

So removing an attachment from the synced vault is a desktop action. The
phone can now save it first, which makes that lossless.

android-client/PLAN.md

@@ -304,6 +304,18 @@ Rangé par ce que ça apporte réellement sur un téléphone.
    que l'utilisateur demande en appuyant, et le message de confirmation nomme
    l'endroit plutôt que de dire « enregistré ».
 
+   **Asymétrie à connaître : le téléphone ne peut pas SUPPRIMER une pièce
+   jointe**, et l'ajouter au patch ne suffirait pas. Le poste ne restaure les
+   pièces jointes que pour une entrée **nouvelle** ([applyRemoteSnapshot](../js/app.sync.js)) ;
+   pour une entrée qu'il connaît déjà, la fusion n'y touche pas. Publier un
+   instantané amputé laisserait donc la ligne intacte dans sa base, et son
+   `buildSyncSnapshot` suivant la remettrait — la suppression reviendrait
+   d'elle-même au tirage d'après.
+
+   Retirer une pièce jointe du coffre synchronisé se fait donc **sur le poste**.
+   Le téléphone, lui, sait maintenant l'enregistrer avant, ce qui rend
+   l'opération sans perte.
+
    Une seule pièce jointe a fait passer le cache de **13 à 174 Ko** : le
    contenu voyage en base64 dans l'instantané, et il est déchiffré en mémoire
    avec le reste. `TVault` lit donc nom, type et taille, et **jette