Dis à l'application quelle version elle est, et sous quelle licence

Page « À propos » (/a-propos) : manuel annoncé à venir, contact, site de
l'auteur, version publiée avec sa date de build, et licence AGPL v3 avec le
lien vers le dépôt — l'AGPL attend que les utilisateurs d'un service en réseau
puissent en obtenir la source, ce lien n'est donc pas un ornement.

L'application ne connaissait pas sa version : elle vivait dans le manifeste du
paquet et dans les tags git, jamais dans le binaire. `build/publier-release.sh`
pose désormais `-p:Version` et `-p:MaBibliDateBuild` ; l'API rend les deux par
`GET /api/version`.

⚠️ L'horodatage est le TÉMOIN de l'injection, et rien ne le calcule côté
MSBuild. Sans lui, la version lue serait le « 1.0.0 » que le SDK pose par
défaut : il se lirait comme une vraie version alors qu'il ne désigne rien, et
c'est exactement la valeur qu'on ira chercher pour diagnostiquer un appareil au
cache dépareillé. Mieux vaut ne rien annoncer — un binaire compilé à la main se
déclare « version de développement », ce qui est vrai.

Autres décisions :

- l'entrée du menu est DÉTACHÉE des six destinations, par un filet au-dessus
  sur téléphone et à gauche en rangée sur PC : « À propos » est une annexe, pas
  une septième destination. Ses règles vivent en feuille GLOBALE, comme tout le
  menu — une règle scopée n'atteint pas ce que rend un NavLink ;
- le « mailto: » reste un lien même hors-ligne : il ne charge aucune page et
  passe la main au client de messagerie, qui sait mettre un message en attente.
  Le site et le dépôt, eux, basculent en boutons désactivés portant leur motif,
  comme les liens d'export des envies ;
- la version est un sixième instantané hors-ligne : on la lit justement quand
  quelque chose ne va pas, et un appareil qu'on soupçonne est souvent celui qui
  n'a plus de réseau. L'écran dit alors que c'est la dernière version vue du
  serveur.

Le point de rupture de 40 rem reste identique dans les deux feuilles, et
/a-propos est inscrite dans la table de remontée des routes.

Vérifié en exécution, l'API lancée : sans injection
`{"numero":null,"publiee":false}`, avec `-p:Version=0.4.1
-p:MaBibliDateBuild=…` `{"numero":"0.4.1","publiee":true}`. Le rendu des écrans
n'a PAS été vérifié en navigateur. 618 tests au vert (605 avant).

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

README.md

@@ -142,6 +142,17 @@ archive `.tar.gz` reproductible, calcule son `sha256`, et met à jour `version`,
 `amd64.url` et `amd64.sha256` dans `mabibli_ynh/manifest.toml` — sauf avec
 `--no-manifest-update`.
 
+Il injecte au passage, dans l'assembly, la **version** (`-p:Version`) et un
+**horodatage de build** (`-p:MaBibliDateBuild`), que la page « À propos » de
+l'application affiche via `GET /api/version`.
+
+⚠️ **L'horodatage est le témoin de l'injection** : sans lui, l'application se déclare
+« version de développement » plutôt que d'afficher le `1.0.0` que le SDK .NET pose par
+défaut. Ce numéro-là se lirait comme une vraie version alors qu'il ne désigne rien — or
+c'est précisément la valeur qu'on va chercher pour diagnostiquer un appareil dont le
+cache est dépareillé. Un `dotnet build` local n'annonce donc aucune version, et c'est
+voulu.
+
 ⚠️ YunoHost lit le manifeste **depuis Gitea**, jamais une copie locale : un manifeste
 corrigé mais non poussé n'existe pas pour le serveur. C'est précisément ce que
 `publier.sh` empêche d'oublier.