Appliquer la mise a jour au demarrage et fermer les fuites de cache

Sur l'application installee sur telephone, le bandeau restait sans effet et
le chargement se figeait a 100 %. La capture montrait le bandeau SANS son
CSS, alors que le script et sa regle sont arrivés dans le meme commit : ce
n'etait pas une mise a jour qui ne s'applique pas, mais une mise a jour
appliquee a moitie.

- MapFallbackToFile n'heritait pas des StaticFileOptions : « / », le
  start_url de la PWA, repartait sans Cache-Control (mesure), donc en cache
  heuristique. A1 avait couvert tous les fichiers statiques sauf celui-la.
- register('service-worker.js') se resolvait contre l'URL du document et non
  contre <base> : une ouverture sur une route profonde visait
  /souhaits/service-worker.js, qui repond 404 (verifie). Tout le hors-ligne
  tombait alors en silence.
- clients.claim() et un rechargement force borne a une fois par session
  donnent un filet a la chaine SKIP_WAITING -> controllerchange -> reload.
- Une version prete dans les 10 s suivant l'ouverture s'applique seule, sans
  bandeau ; au-dela on repasse par le clic, pour ne pas arracher une saisie.

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

MaBibli.Api/Program.cs

@@ -99,6 +99,12 @@ app.MapRevuesEndpoints();
 app.MapBibliographieEndpoints();
 app.MapIdentiteEndpoints();
 
-app.MapFallbackToFile("index.html");
+// ⚠️ Le fallback a son propre pipeline : il NE passe PAS par les StaticFileOptions posées
+// ci-dessus. Sans lui repasser les mêmes options, « / » — c'est-à-dire le start_url de la PWA,
+// la seule URL qu'ouvre l'application installée — repartait sans aucun Cache-Control, donc en
+// cache heuristique du navigateur. Mesuré : /index.html portait bien l'en-tête, « / » non.
+// C'est la coquille HTML qui décide de tout le reste : la servir périmée suffit à mélanger deux
+// versions sur l'appareil.
+app.MapFallbackToFile("index.html", optionsFichiersStatiques);
 
 app.Run();