Envois simultanes serialises, et pas de controle d'espace disque

Deux defauts trouves en relisant le code de l'envoi en morceaux.

Le verrou global etait tenu pendant l'ecriture disque et le renommage.
Or le client lance un envoi PAR FICHIER JOINT, de front : trois fichiers
s'attendaient donc les uns les autres, chacun bloquant les suivants
jusqu'a sa derniere tranche. Le verrou global ne protege plus que la
table des sessions ; l'ecriture se fait sous le verrou de la session. Un
drapeau `busy` empeche le menage de fermer un fichier sous les pieds de
la requete qui l'ecrit. Test : 3 fichiers de 20 Mo en parallele, contenus
distincts, aucun melange.

Rien ne verifiait la place disque : un envoi d'un gigaoctet pouvait
remplir le volume de la machine qui fait tourner le modele, ou vivent
aussi llama-server, la base et les journaux. Le client annonce la taille
au premier morceau, le serveur refuse en 507 s'il ne reste pas la place
plus 512 Mo de marge. La taille annoncee n'engage que le client : le
plafond reel reste verifie morceau par morceau.

Aussi : Sync() avant publication (un tampon non vide donne un fichier
incomplet), et cote client une tranche vide sans marque de fin arrete le
telechargement au lieu de boucler indefiniment.

RELEASE_NOTES.md

@@ -1,4 +1,4 @@
-La limite d'envoi de fichiers passe de 24 Mo à 1 Go.
+La limite d'envoi de fichiers passe de 24 Mo à 1 Go, et le téléchargement depuis ajean.link est réparé.
 
 ## Des fichiers d'un gigaoctet
 
@@ -8,11 +8,23 @@ Le fichier part maintenant par tranches de 8 Mo. Le navigateur n'en lit qu'une
 
 Au passage, la vignette affiche l'avancement en pourcentage : sur un gros fichier, l'anneau qui tournait sans rien dire n'était pas d'un grand secours.
 
+Avant d'entamer un envoi, AJEAN vérifie qu'il reste de la place sur le disque et refuse franchement s'il n'y en a pas — remplir le volume de la machine qui fait tourner le modèle serait autrement plus ennuyeux qu'un envoi rejeté.
+
 Un envoi interrompu — onglet fermé, réseau coupé, service redémarré — ne laisse rien derrière lui : le fichier partiel est effacé au bout de dix minutes, et au démarrage du service.
 
-Ce qui n'a pas changé : le dépôt n'a toujours lieu qu'à l'envoi du message, et l'accès distant fonctionne pareil, les tranches passant par le tunnel chiffré comme le reste.
+## Télécharger un fichier depuis ajean.link
 
-Pensez tout de même à la place disque de la machine qui héberge AJEAN : les fichiers envoyés s'accumulent dans `uploads/`, à l'intérieur du dossier de travail de l'IA.
+Depuis l'accès distant, cliquer sur un fichier proposé par l'IA téléchargeait un contenu JSON illisible à la place du fichier.
+
+La cause tient à la façon dont l'accès distant chiffre les échanges : toute réponse est réemballée en JSON avant de vous parvenir, et des données binaires n'y survivent pas. Le fichier était donc détruit en chemin, quel que soit son type.
+
+Votre serveur signale maintenant à l'interface qu'elle est derrière le tunnel, et lui envoie le fichier sous une forme qui traverse intact, toujours en tranches pour ne pas le charger entier en mémoire. En local, rien ne change : le fichier est servi directement, sans détour.
+
+Le même défaut abîmait l'export de conversation au format Markdown, qui revenait truffé de guillemets et d'échappements. Corrigé aussi.
+
+## Aussi
+
+- Plusieurs fichiers joints en même temps s'envoient désormais en parallèle. Ils s'attendaient les uns les autres, chaque envoi bloquant les suivants jusqu'à sa dernière tranche.
 
 ## Mise à jour
 
@@ -25,3 +37,5 @@ Puis redémarrez l'interface :
 ```bash
 ajean ui restart
 ```
+
+Pensez à la place disque de la machine qui héberge AJEAN : les fichiers envoyés s'accumulent dans `uploads/`, à l'intérieur du dossier de travail de l'IA, et rien ne les efface pour l'instant.