Range --archive-seule au lieu de le supprimer, et mesure la RAM

Le mode etait justifie dans CLAUDE.md comme « la brique reutilisable en CI ».
C'etait faux : le README du depot du code s'en sert depuis toujours comme
chemin de reprise a la main quand publier.sh echoue en cours de route. Il a
donc failli partir sur une justification erronee.

Garde et range : 8 ramifications ramenees a 5, dont une seule assouplit encore
un garde-fou, contre trois auparavant. Deux defauts reels en sont sortis — un
depot sale n'etait PAS signale dans ce mode, et la version y retombait sur
celle deja publiee, piege que le README documentait au lieu de le corriger.

refuser() separe le constat du conseil : le constat vaut dans les deux modes,
« choisissez un numero libre » est faux en reprise, ou le tag vise est
justement celui qu'on veut retrouver.

Le depot git devient une exigence inconditionnelle en tete, ce qui supprime
quatre tests -d .git disperses plus bas.

Les cinq variables d'environnement jumelles disparaissent : chacune doublait
une option qu'elle repetait, l'aide en listait dix pour cinq reglages, et rien
ne disait laquelle l'emportait.

ram.runtime passe de 200M a 256M. Mesure sur le serveur : pic reel de
208 793 600 o, soit 199,1 Mio, contre 200M declares — 0,4 % de marge, c'est-a-
dire aucune. systemctl show -p MemoryPeak ne renvoie rien sur ce serveur et
reussit en silence ; c'est le cgroup qui garde le maximum.

Les deux doc/*_fr.md, identiques octet pour octet a leurs jumeaux, sont
supprimes : YunoHost retombe sur les fichiers par defaut, deja en francais.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

manifest.toml

@@ -37,8 +37,33 @@ sso = true
 # ~170 Mo de publish self-contained (runtime .NET embarqué), plus la base et la marge
 # de décompression de l'archive.
 disk = "500M"
+
+# ⚠️ `ram.build` ne désigne AUCUNE compilation : rien n'est compilé sur le serveur, c'est
+# tout l'intérêt du self-contained. Il couvre le téléchargement et la décompression de
+# l'archive de 69 Mo. Ne pas aller chercher la valeur du côté d'un build .NET.
 ram.build = "50M"
-ram.runtime = "200M"
+
+# Mesuré sur le serveur le 2026-08-22, service en marche :
+#     cat /sys/fs/cgroup/system.slice/mabibli.service/memory.peak  ->  208 793 600 o
+# soit 199,1 Mio de pic, contre 200M déclarés jusqu'ici : 0,4 % de marge, c'est-à-dire
+# aucune. Porté à 256M.
+#
+# ⚠️ `systemctl show -p MemoryPeak` ne renvoie RIEN sur ce serveur — la commande réussit
+# en silence et l'on croit lire un pic là où l'on ne lit rien. Passer par le cgroup.
+#
+# ⚠️ Le chiffre MAJORE le besoin : `memory.peak` compte le cache de fichiers, donc une
+# part des 69 Mo de binaire mappé, récupérable sous pression — et le GC de .NET se serre
+# sur une machine étroite. Mais YunoHost compare une déclaration statique à la RAM
+# disponible, sans faire cette nuance. L'asymétrie tranche : un refus d'installation est
+# visible et se contourne, un OOM survient plus tard, sous une opération lourde, sans que
+# rien ne désigne la cause.
+#
+# ⚠️ Le pic n'est PAS le lookup ISBN, contrairement à l'intuition — une notice. C'est
+# « Nouveautés » sur un auteur très réédité : jusqu'à dix pages de 100 notices SRU en
+# parallèle, plus le catalogue entier chargé pour le rapprochement. Ce cas-là n'a pas
+# encore été mesuré, et il croît avec la taille de la bibliothèque : à reprendre le jour
+# où le fonds aura beaucoup grossi.
+ram.runtime = "256M"
 
 [install]