Renvoie la documentation vers le README du dépôt du code

publier.sh enchaîne la publication de bout en bout : version déduite de la
précédente, archive, manifeste, commit et push du paquet, tag et push du code,
avec vérification côté distant. Seul le dépôt de l'archive dans la release
Gitea reste manuel — l'URL est rappelée en fin de sortie.

PUBLICATION.md et A_FAIRE.md sont supprimés : leur contenu vit désormais dans
le README de mabibli, point d'entrée unique du projet. doc/DESCRIPTION.md et
doc/ADMIN.md restent ici, YunoHost les lisant lui-même.

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

README.md

@@ -4,74 +4,32 @@ Paquet d'installation de [MaBibli](https://git.akbar.nohost.me/mathieu/mabibli),
 gestion de bibliothèque personnelle (catalogue, prêts, scan ISBN).
 
 Ce dépôt **ne contient aucun code C#**. Il porte uniquement de quoi installer sur YunoHost une
-archive déjà compilée : le manifeste, les configurations nginx et systemd, et les scripts
-d'installation.
+archive déjà compilée : le manifeste, les configurations nginx et systemd, les scripts
+d'installation, et les scripts de publication.
 
-## Contenu
+## 📖 Toute la documentation est dans le dépôt du code
 
-| Fichier | Rôle |
-|---|---|
-| `manifest.toml` | Identité, version, URL de l'archive et son `sha256`, ressources (utilisateur système, répertoires, port, permissions) |
-| `conf/systemd.service` | Unité du service — écoute sur `127.0.0.1`, base dans le répertoire de données, durcissement |
-| `conf/nginx.conf` | Reverse proxy et intégration SSOwat |
-| `scripts/_common.sh` | Variables partagées et sauvegarde/restauration cohérente de la base SQLite |
-| `scripts/install` `remove` `upgrade` `backup` `restore` | Cycle de vie de l'application |
-| `build/publier-release.sh` | Compile, archive, calcule le `sha256` et met à jour `manifest.toml` |
+Elle a été regroupée dans **[le README de `mabibli`](https://git.akbar.nohost.me/mathieu/mabibli#readme)**,
+qui est le point d'entrée unique du projet : contenu et points de conception du paquet,
+publication d'une version, mise en production pas à pas, montée de version, retour arrière,
+désinstallation, et contraintes permanentes.
+
+Il n'y a qu'une seule chaîne de publication et un seul projet : deux jeux de documentation
+finissaient par diverger, et l'on ne savait plus lequel faisait autorité.
+
+Ne restent ici que les deux fichiers que **YunoHost lit lui-même** et qui doivent donc vivre
+à côté du manifeste :
+
+- `doc/DESCRIPTION.md` — présentation affichée dans le catalogue d'applications
+- `doc/ADMIN.md` — authentification, emplacement des données, sauvegarde ; affichée dans
+  l'interface d'administration une fois l'application installée
 
 ## Publier une nouvelle version
 
-Le serveur ne compile jamais : il télécharge une archive déjà produite. La chaîne est donc
-« compiler ici, déposer une release, mettre à jour le manifeste ».
-
 ```bash
 # Depuis ce dépôt, avec le dépôt du code à côté (../mabibli)
-./build/publier-release.sh --version 0.1.1
+./build/publier.sh
 ```
 
-Le script :
-
-1. lance `dotnet publish MaBibli.Api -c Release -r linux-x64 --self-contained` ;
-2. vérifie que le binaire est là, que `wwwroot/` a bien été embarqué, et que **toutes** les
-   ressources référencées par `index.html` existent réellement dans le publish ;
-3. produit `build/dist/mabibli-<version>-linux-x64.tar.gz`, de façon reproductible ;
-4. en calcule le `sha256` ;
-5. réécrit `version`, `amd64.url` et `amd64.sha256` dans `manifest.toml`.
-
-Restent à faire à la main : créer le tag et la release sur Gitea, y téléverser l'archive, puis
-committer et **pousser** `manifest.toml` — YunoHost lit le manifeste depuis Gitea, pas la copie
-locale.
-
-📖 **La marche à suivre complète est dans [`PUBLICATION.md`](PUBLICATION.md)** : première mise en
-production, montée de version (avec les contrôles à chaque étape), retour arrière, et
-désinstallation.
-
-Le script ne dépend d'aucun environnement de CI : tout passe par des options ou des variables
-d'environnement (`MABIBLI_SOURCE_DIR`, `MABIBLI_VERSION`, `MABIBLI_BASE_URL`,
-`MABIBLI_OUTPUT_DIR`), il ne pose aucune question et s'arrête à la première erreur. Il est donc
-utilisable tel quel dans Gitea Actions le jour où un runner sera disponible.
-
-## Points de conception
-
-**Le service n'écoute que sur `127.0.0.1`.** L'application déduit l'identité de l'en-tête
-`YNH_USER` injecté par SSOwat ; cet en-tête n'est digne de confiance que si nginx est le seul
-chemin d'accès. Un service exposé sur le réseau permettrait de forger `YNH_USER` et de
-contourner le portail. La contrainte est écrite dans `conf/systemd.service` (`ASPNETCORE_URLS`)
-et le port n'est pas ouvert au pare-feu.
-
-**Aucune compilation sur le serveur.** Le publish est *self-contained* : il embarque son propre
-runtime .NET, donc aucun paquet `dotnet-runtime` n'est nécessaire. `ynh_setup_source` vérifie le
-`sha256` de l'archive avant de la déployer.
-
-**Les données survivent aux mises à jour.** La base SQLite vit dans le répertoire de données, pas
-à côté du binaire ; `upgrade` ne remplace que le répertoire d'installation.
-
-**La sauvegarde passe par l'API de sauvegarde en ligne de SQLite.** La base est en mode WAL :
-copier le seul fichier `.db` d'une base active peut ne rien sauvegarder du tout. Voir
-`doc/ADMIN.md`.
-
-## Documentation
-
-- `doc/DESCRIPTION.md` — présentation affichée dans le catalogue YunoHost
-- `doc/ADMIN.md` — authentification, emplacement des données, sauvegarde, contraintes
-- `PUBLICATION.md` — mise en production et montée de version, pas à pas
-- `A_FAIRE.md` — contraintes permanentes et journal des points réglés
+Le détail — ce que le script vérifie, ce qui reste manuel, et la marche à suivre côté serveur —
+est dans le README de `mabibli`.