Documenter un bloquant : le publish de l'API casse index.html

Verifie en executant le binaire publie : la racine repond 200 mais les
scripts de demarrage renvoient 404, donc l'application publiee affiche une
page blanche. Les placeholders d'empreinte restent litteraux alors que
seuls les fichiers empreintes existent sur disque.

Preexistant depuis la phase 1 : ma verification d'alors se limitait au code
HTTP de la racine, ce qui ne prouve pas que l'application demarre.

Consigne les trois pistes deja essayees sans succes pour eviter qu'on les
retente, et signale que le developpement n'est pas affecte.

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

CLAUDE.md

@@ -223,6 +223,30 @@ dotnet publish MaBibli.Api -c Release -r linux-x64 --self-contained
 
 Le self-contained embarque le runtime .NET dans le binaire : **aucun `dotnet-runtime` à installer** côté serveur, pas de conflit de versions. C'est le modèle de `radarr_ynh`.
 
+### ⚠️ BLOQUANT CONNU : le publish de l'API produit un `index.html` cassé
+
+**Constaté le 2026-08-18, non résolu. À corriger impérativement avant tout packaging YunoHost.**
+
+`dotnet publish MaBibli.Api -c Release` produit un `wwwroot/index.html` dont les placeholders ne sont **pas** substitués :
+
+```html
+<script type="importmap"></script>                                  <!-- vide -->
+<script src="_framework/blazor.webassembly#[.{fingerprint}].js">    <!-- littéral -->
+```
+
+Or seuls les noms **empreintés** existent sur disque (`blazor.webassembly.958z1vx7fr.js`). Résultat vérifié en exécutant le binaire publié : la racine répond **200**, mais le script de démarrage et `_framework/dotnet.js` renvoient **404**. L'application publiée affiche une **page blanche** — elle ne démarre pas.
+
+`dotnet publish MaBibli.Client` seul produit au contraire un `index.html` correct : le défaut vient de l'hébergement du client par l'API, qui embarque le `wwwroot` de *build* du client plutôt que son `wwwroot` *publié*.
+
+**Piège de diagnostic** : vérifier que `/` renvoie 200 ne prouve rien — c'est ce qui a fait passer le défaut inaperçu à la phase 1. Il faut vérifier les scripts que `index.html` référence réellement, ou charger la page dans un navigateur.
+
+Pistes déjà essayées **sans succès** (inutile de les retenter à l'identique) :
+- `<OverrideHtmlAssetPlaceholders>true</OverrideHtmlAssetPlaceholders>` sur `MaBibli.Api` ;
+- `<WasmFingerprintAssets>false</WasmFingerprintAssets>` sur le client — donne bien un `dotnet.js` stable, mais `blazor.webassembly.js` reste empreinté car il provient des assets du package framework ;
+- `<StaticWebAssetsFingerprintContent>false</StaticWebAssetsFingerprintContent>` sur les deux projets.
+
+Le développement n'est pas affecté : `dotnet run --project MaBibli.Api` fonctionne normalement.
+
 ### Deux dépôts distincts
 
 | Dépôt | Contenu | Rôle |