Kein alter Stand mehr im Zwischenspeicher, Einsetzer heisst HoneyBar-Proxy

Die HoneyBar kommt bei fremden Apps ueber deren eigenen Ursprung — das
loest CSP, CORS und COEP auf einmal, setzt sie aber auch deren Zwischen-
speicher aus. Eine alte HoneyBar dort sieht aus wie ein Fehler in HoneyOS.
Statt no-cache jetzt no-store, must-revalidate; dazu ein Abschnitt in der
README, wie man einen haengengebliebenen Stand erkennt.

Und der nginx davor heisst nicht mehr 'Einsetzer', sondern HoneyBar-Proxy
(Dienst und Behaelter honeybar-proxy bzw. <app>-honeybar). Er ist ein
Reverse Proxy, der die HoneyBar einsetzt — der alte Name sagte das
Gegenteil von dem, was man im docker ps sehen will. LEISTE_PORT heisst
jetzt HONEYBAR_PROXY_PORT.

main.go

@@ -224,7 +224,13 @@ func (s *Server) cors(next http.Handler) http.Handler {
 
 func noCache(next http.Handler) http.Handler {
 	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
-		w.Header().Set("Cache-Control", "no-cache")
+		// no-store, nicht no-cache: Die Oberflaeche und vor allem honeybar.js
+		// muessen bei jedem Aufruf frisch kommen. Sie werden ueber den eigenen
+		// Ursprung der fremden App ausgeliefert und geraten damit in deren
+		// Zwischenspeicher — und in den ihres Service Workers, falls sie einen
+		// hat. Eine alte HoneyBar dort ist von aussen nicht zu erkennen: Sie
+		// sieht aus wie ein Fehler in HoneyOS.
+		w.Header().Set("Cache-Control", "no-store, must-revalidate")
 		// Die HoneyBar wird von fremden Ursprüngen geladen — das ist ihr Zweck.
 		// Apps, die selbst COEP „require-corp" setzen (alles mit WASM oder
 		// SharedArrayBuffer, etwa BentoPDF), lehnen sonst jede fremde Datei ab,