Docs : première release web publiée (v1.4.10, cloudyfy) + statut conteneur réel

- §10 : v1.4.10 = première release Gitea web (zip vérifié par
  téléchargement via scripts/publish-release.py, construit par git archive
  AU TAG) ; farewell en attente de la création du repo
- §10 : statut conteneur = build + run réels validés localement (colima) ;
  container-test en configuration durcie vert ; deux problèmes du premier
  test documentés (tmpfs /tmp requis en read-only, case header_json curl)
- README : lien releases + statut conteneur

README.md

@@ -18,8 +18,10 @@
 > endocrinologue.
 
 - **Statut** : web v1.4.10 — portage de l'Android v1.4.10 · **121 tests verts** ·
-  E2E navigateur ✅ · lint/i18n ✅
+  E2E navigateur ✅ · conteneur testé en configuration durcie ✅ · lint/i18n ✅
 - **Journal des versions web** : [docs/CHANGELOG.md](docs/CHANGELOG.md)
+- **Releases** : [gitea.cloudyfy.fr/Siphonight/HormoneTrack-web/releases](https://gitea.cloudyfy.fr/Siphonight/HormoneTrack-web/releases)
+  (zip de déploiement statique vérifié par téléchargement)
 - **Versionnage** : les versions web sont **alignées sur l'Android porté**
   (web v1.4.10 = toutes les fonctionnalités de l'Android v1.4.10, sauf les
   impossibilités structurelles du navigateur) — cf

docs/DEVELOPPEMENT.md

@@ -458,10 +458,13 @@ Règles de code (appliquées partout, à conserver) :
 Les releases web sont **SYNCHRONISÉES avec les releases APK** (décision du
 8 sept. 2026) : chaque feature release de l'Android est portée et tagguée
 au MÊME numéro dans ce dépôt — l'utilisatrice a toujours la parité des
-fonctionnalités (sauf impossibilités structurelles §12). La publication
+fonctionnalités (sauf impossibilités structurelles §12).
-Gitea (release avec assets) du côté web est GELÉE tant que la qualité n'est
+
-pas validée au standard APK : en attendant, une release web = commit + tag
+**v1.4.10 = la première release web publiée (8 sept. 2026, cloudyfy)** :
-UNIQUEMENT.
+tag + release Gitea avec l'archive zip de déploiement, APRES validation
+complète (121 tests unitaires + E2E navigateur local + container-test réel
+en configuration durcie). Le dépôt farewell reste en attente de la création
+du repo (one-shot côté Gitea).
 
 ### Remotes
 
@@ -502,11 +505,13 @@ push initial v1.2.3, cf doc Android §16.)
 4. **Releases Gitea** :
    - Android : `publish-release.py` sur les deux instances (2 APK), cf doc
      Android §16.bis ;
-   - Web : **GELÉ** tant que la parité qualité n'est pas validée — sinon
+   - Web : `python3 scripts/publish-release.py cloudyfy vX.Y.Z` —
-     créer la release avec le corps = section `docs/CHANGELOG.md` et, si
+     crée/met à jour la release (corps = section `docs/CHANGELOG.md`) et
-     un jour on distribue un zip, le vérifier par téléchargement (leçon
+     attache l'archive `HormoneTrack-web-vX.Y.Z.zip` construite PAR
-     #43 Android : une invocation fait tout, les uploads rapprochés se
+     `git archive` AU TAG (jamais le working tree), vérifiée par
-     remplacent mutuellement).
+     téléchargement (uid des leçons #37/#43 Android : une invocation fait
+     tout, vérif par téléchargement, échec bruyant). Idem `farewell` une
+     fois le repo créé.
 5. **Smoke-test** : Android sur le Pixel 9 (checklist §21 Android) ; web
    sur le navigateur : import d'un backup réel, pan/zoom, export/import,
    langue.
@@ -564,13 +569,16 @@ HRT_E2E_BASE=http://127.0.0.1:8080 node scripts/e2e.mjs
 `/js/ui/app.js`, `/docs/CHANGELOG.md` — les mêmes que le smoke HTTP de
 `check.sh --with-serve`.
 
-**Statut (8 sept. 2026)** : fichiers + docs prêts et relus — build NON
+**Statut (8 sept. 2026)** : build et run RÉELS validés localement via
-exécuté localement (aucun daemon Docker sur la machine de dev, CLI seule) ;
+colima (daemon Docker léger, 2 CPU / 2 Go) — `scripts/container-test.sh`
-la configuration compose (`read_only`/tmpfs) est le pattern standard de
+vert en configuration DURCIE (healthcheck healthy, endpoints, headers,
-nginx-unprivileged, à valider au premier `docker compose up` sur l'hôte
+gzip, MIME, E2E complet contre le conteneur). Deux problèmes réels trouvés
-cible. Si le durcissement pose problème sur ton NAS : retirer
+et corrigés au premier test : (a) tmpfs `/tmp` REQUIS en read-only (les
+temporaires de nginx-unprivileged — « mkdir /tmp/proxy_temp failed »
+sinon), (b) curl `%header_json` minuscule les clés (bug du TEST, pas du
+conteneur). Si le durcissement pose problème sur ton NAS : retirer
 `read_only`/`tmpfs`/`security_opt` du compose (aucune perte de sécurité
-cruciale — le conteneur ne détient rien, cf plus haut).
+cruciale — le conteneur ne détient rien).
 
 ## 11. Bugs potentiels évités pendant le portage