docs: durchgaengig HoneyBar statt Leiste

Der Dienst im Beispiel heisst jetzt einsetzer — er ist nicht die HoneyBar,
er setzt sie ein. Zusammensetzungen wie Menueleiste, Taskleiste und
Statusleiste bleiben, die meinen etwas anderes.

Dazu in IDEAS notiert, dass HoneyBar und Menueleiste zwei getrennte Stilsaetze
sind und schon einmal auseinandergelaufen ist.

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

IDEAS.md

@@ -14,10 +14,10 @@ wirklich hinschaut.
 Ohne diese Stücke ist alles danach nicht möglich. Reihenfolge nach dem
 Verhältnis von Aufwand zu spürbarer Wirkung.
 
-### 1.1 Die Leiste trägt deine Röhre — ✅ erledigt (24.08.2026)
+### 1.1 Die HoneyBar trägt deine Röhre — ✅ erledigt (24.08.2026)
 
-Die Leiste liest ihre Farben nicht mehr fest, sondern aus derselben Antwort, mit
-der sie die App-Liste holt. Röhre in HoneyOS auf grün → die Leiste in Aether ist
+Die HoneyBar liest ihre Farben nicht mehr fest, sondern aus derselben Antwort, mit
+der sie die App-Liste holt. Röhre in HoneyOS auf grün → die HoneyBar in Aether ist
 grün, ohne dass Aether angefasst wird. `glow` und `scanlines` gelten dort ebenso.
 
 **Ging entgegen der ersten Einschätzung auch über Site-Grenzen hinweg.** Ich
@@ -26,7 +26,7 @@ hatte notiert, das scheitere daran, dass der Browser die Sitzung nicht mitschick
 das Aussehen gleich mit. Deshalb liefert `/api/apps` jetzt `{apps, settings}`
 statt nur einer Liste.
 
-Offen bleibt: Bei mehreren Nutzern trägt die Leiste die Farbe des
+Offen bleibt: Bei mehreren Nutzern trägt die HoneyBar die Farbe des
 Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da
 gerade schaut.
 
@@ -51,10 +51,10 @@ mit Symbolen — heute sind es Textknöpfe. Bei zwei Apps geht das noch, ab vier
 wird es eng, am Handy sofort.
 
 **Der eigentliche Punkt: die Symbole.** Das Pixelraster lebt in `os.js`
-(`GLYPHS`), die Leiste kennt es nicht. Zwei Wege:
+(`GLYPHS`), die HoneyBar kennt es nicht. Zwei Wege:
 
 - **Pixelglyphen teilen** — `GLYPHS` + `glyphSvg()` in eine eigene Datei, die
-  Desktop und Leiste beide laden. Kein Upload, kein Speicher, passt zum Look.
+  Desktop und HoneyBar beide laden. Kein Upload, kein Speicher, passt zum Look.
   Nachteil: nur die eingebauten Symbole.
 - **Echte Bilder** — pro App eine Bildadresse oder ein Upload in HoneyOS.
   Flexibler, aber: Speicher, Größenbegrenzungen, Auslieferung, und der
@@ -67,7 +67,7 @@ Bild in HoneyOS hinterlegen, statt nur aus den eingebauten Glyphen zu wählen.
 Nicht als Ersatz für die Pixelglyphen, sondern daneben: Glyphe als Rückfall,
 wenn kein Bild da ist.
 
-**Das Logo gehört ausdrücklich auch in die Leiste**, nicht nur auf den
+**Das Logo gehört ausdrücklich auch in die HoneyBar**, nicht nur auf den
 Schreibtisch — dort ist die Unterscheidung am nötigsten, weil die Knöpfe klein
 sind und nebeneinanderstehen. Damit ist die geteilte Symbolquelle aus 1.3
 Voraussetzung: Beide Seiten müssen dasselbe Bild bekommen, sonst pflegt man es
@@ -82,18 +82,18 @@ Was daran zu bauen ist, in dieser Reihenfolge:
 2. **Ausliefern** — unter einer Adresse je App, mit einem Versionsanteil, damit
    ein Austausch nicht im Cache hängen bleibt (Aether macht das beim Logo
    schon so).
-3. **In der Leiste anzeigen** — über die Site-Grenze hinweg ein `<img>` von
+3. **In der HoneyBar anzeigen** — über die Site-Grenze hinweg ein `<img>` von
    HoneyOS. Das geht ohne Sitzung, Bilder unterliegen der CORS-Regel nicht.
 
 **Vorher zu klären:** Sollen Bilder in den Retro-Look eingepasst werden
 (auf wenige Farben reduziert, hart gerastert) oder bunt bleiben? Ein
 Original-Logo mit Farbverlauf neben Pixelglyphen sieht schnell nach Fremdkörper
-aus. Ein Filter in der Leiste wäre billig zu haben und ließe sich abschalten.
+aus. Ein Filter in der HoneyBar wäre billig zu haben und ließe sich abschalten.
 
 ### 1.3b Reihenfolge der Apps
 
 Heute stehen die Apps in der Reihenfolge, in der sie eingetragen wurden. Bei
-zwei Stück ist das keine Frage; ab vier oder fünf schon, und in der Leiste
+zwei Stück ist das keine Frage; ab vier oder fünf schon, und in der HoneyBar
 zuerst — dort ist der Platz am knappsten und die Reihenfolge entscheidet, was
 man am Handy noch sieht.
 
@@ -107,7 +107,7 @@ Möglichkeiten:
 | feste Reihenfolge + Rest alphabetisch | mittel | Mischung |
 
 → **Vorschlag: von Hand sortieren**, dieselbe Reihenfolge auf Schreibtisch und
-Leiste. Zählen, wie oft etwas benutzt wird, heißt Nutzungsdaten speichern —
+HoneyBar. Zählen, wie oft etwas benutzt wird, heißt Nutzungsdaten speichern —
 dafür ist der Nutzen hier zu klein. **Zu entscheiden, sobald die vierte App
 dazukommt**, nicht vorher.
 
@@ -187,16 +187,16 @@ Eines bauen, benutzen, dann entscheiden.
 - **Speicherplatz** (Aether) — eine Zahl, ein Balken, billig zu bauen
 - **Letzte Notizen** (InkNote) — braucht 1.3, kommt also später
 
-### Wetter in der Leiste, neben der Uhr — ✅ gebaut (25.08.2026)
+### Wetter in der HoneyBar, neben der Uhr — ✅ gebaut (25.08.2026)
 
 **Steht.** Zwei Schalter in den Einstellungen, unabhängig voneinander: auf dem
-Schreibtisch, in der Leiste, beides oder keins. Die Stadt wird einmal gesucht
+Schreibtisch, in der HoneyBar, beides oder keins. Die Stadt wird einmal gesucht
 und mit ihren Koordinaten gespeichert; der Server holt das Wetter und legt es
 zehn Minuten beiseite, die Oberflächen zeigen nur, was er hergibt.
 
 Offen geblieben ist eines mit Absicht: **Die Stadt lässt sich nur auf dem
-Schreibtisch ändern, nicht aus der Leiste heraus.** Ein Klick auf das Symbol
-führt dorthin. Der Grund ist derselbe wie bei allem anderen in der Leiste: Sie
+Schreibtisch ändern, nicht aus der HoneyBar heraus.** Ein Klick auf das Symbol
+führt dorthin. Der Grund ist derselbe wie bei allem anderen in der HoneyBar: Sie
 liest über den Schlüssel und darf nichts schreiben — und über eine Site-Grenze
 wüsste sie nicht, für wen sie es täte. Liegt alles unter einer Domain, wäre es
 nachrüstbar.
@@ -218,7 +218,7 @@ was sich noch ändern kann, und lässt sich an einem Abend fertig bauen. Damit
 beantwortet es die eigentliche Frage — schaut man überhaupt hin? — ohne dass
 vorher das halbe Fundament stehen muss.
 
-Und es ist das erste Widget, das **in der Leiste** lebt statt auf dem
+Und es ist das erste Widget, das **in der HoneyBar** lebt statt auf dem
 Schreibtisch. Es ist damit zugleich der Probelauf für den Rahmen weiter unten.
 
 **Die Abfrage gehört auf den Server, nicht in den Browser.** Open-Meteo braucht
@@ -241,10 +241,35 @@ Zu klären, wenn es soweit ist:
 - **Kein Netz, kein Wetter.** Dann verschwindet das Symbol, statt eine Zahl von
   gestern als heutige auszugeben.
 
-### Die Leiste ohne `unsafe-inline`
+### Zwei Leisten, zwei Stilsätze
 
-Fremde Apps bekommen die Leiste über den Reverse Proxy (siehe README). Dabei
-muss deren CSP heute `style-src 'unsafe-inline'` erlauben, weil die Leiste ihre
+Die HoneyBar in fremden Apps (`honeybar.js`, eigenes CSS im Shadow DOM) und die
+Menüleiste des Schreibtischs (`.menubar` in `style.css`) sehen gleich aus, sind
+aber getrennter Code — rund 19 Regeln hier, 30 dort, alle von Hand
+gleichgehalten.
+
+**Das ist bereits einmal auseinandergelaufen:** Das Wetter stand zuerst nur in
+`honeybar.js`, und der Schalter „in der honeybar" schien auf dem Schreibtisch
+wirkungslos (25.08.2026). Es wird wieder passieren.
+
+Zwei Auswege:
+
+- **Die Schreibtisch-Menüleiste durch `honeybar.js` ersetzen.** Ein Stilsatz,
+  eine Anatomie, und was die HoneyBar kann, kann der Schreibtisch automatisch
+  auch. Kostet: Die Menüleiste hat Dinge, die die HoneyBar nicht hat
+  (Einstellungsknopf, Abmelden, Avatar) — die müssten hinein, und die HoneyBar
+  ist bewusst schlank.
+- **Die Farb- und Maßangaben in eine gemeinsame Datei ziehen**, die beide
+  einbinden. Kleiner Eingriff, löst aber nur die Hälfte: Aufbau und Verhalten
+  bleiben doppelt.
+
+→ Ersteres ist das Richtige, sobald die HoneyBar mehr kann als heute (Widgets,
+Systemmenü). Vorher lohnt der Umbau nicht.
+
+### Die HoneyBar ohne `unsafe-inline`
+
+Fremde Apps bekommen die HoneyBar über den Reverse Proxy (siehe README). Dabei
+muss deren CSP heute `style-src 'unsafe-inline'` erlauben, weil die HoneyBar ihre
 Stile im Shadow DOM mitbringt — ohne das erscheint sie schwarz auf schwarz.
 Gemessen am 28.08.2026 an einer nachgebauten fremden App.
 
@@ -253,25 +278,25 @@ Shadow DOM per `<link>` einbinden. Dann genügt `style-src 'self' https://honeyo
 und die CSP der fremden App bleibt streng. Kostet eine zweite Anfrage, die
 zwischengespeichert wird.
 
-Zu prüfen ist dabei, was sonst noch inline gesetzt wird: die Lage der Leiste
+Zu prüfen ist dabei, was sonst noch inline gesetzt wird: die Lage der HoneyBar
 selbst und der Innenabstand, den sie der Seite verpasst. Über die CSSOM gesetzte
 Stile (`el.style.x = …`) fallen nicht unter die CSP — was im Markup steht, schon.
 
-### Widgets in der Leiste selbst
+### Widgets in der HoneyBar selbst
 
 Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch
-ist aber die Seite, die man am seltensten offen hat — die Leiste dagegen ist
-überall. Naheliegend also: ein Knopf in der Leiste klappt dasselbe Widget als
+ist aber die Seite, die man am seltensten offen hat — die HoneyBar dagegen ist
+überall. Naheliegend also: ein Knopf in der HoneyBar klappt dasselbe Widget als
 kleines Feld auf, ohne die App zu verlassen.
 
 Technisch ist das dieselbe Sache wie 1.6, nur ein zweites Zuhause für denselben
 Inhalt: Der Rahmen muss dann drei Formen können — Fenster, Kachel, Aufklappfeld.
 Das ist beim **Bauen** von 1.6 zu bedenken, hinterher wird es teuer.
 
-**Eine Einschränkung vorweg:** Die Leiste läuft in einer fremden App. Ein
-Aether-Widget in der Leiste **von InkNote aus** braucht deshalb dasselbe, was
+**Eine Einschränkung vorweg:** Die HoneyBar läuft in einer fremden App. Ein
+Aether-Widget in der HoneyBar **von InkNote aus** braucht deshalb dasselbe, was
 1.4 für den Schreibtisch regelt, nur für einen weiteren Ursprung. In der App
-selbst (Aether-Widget in Aethers eigener Leiste) ist es geschenkt.
+selbst (Aether-Widget in Aethers eigener HoneyBar) ist es geschenkt.
 
 → Anfangen mit **letzte Dateien**. Wenn du danach merkst, dass du morgens
 wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
@@ -291,10 +316,10 @@ wirklich draufschaust, lohnt der Rest. Wenn nicht, war es ein Abend.
 
 ## Offene Entscheidungen
 
-### Wie sichtbar darf die Leiste sein?
+### Wie sichtbar darf die HoneyBar sein?
 
 **Teilweise beantwortet:** „ausblenden" heißt seit dem 24.08. „einklappen" — es
-bleibt ein 3 px hoher Strich am oberen Rand stehen, ein Klick holt die Leiste
+bleibt ein 3 px hoher Strich am oberen Rand stehen, ein Klick holt die HoneyBar
 zurück. Vorher war das eine Einbahnstraße: wer einmal ausgeblendet hatte, kam
 nur über die Entwicklerkonsole wieder heran. `?honeybar=1` an der Adresse
 funktioniert als Notausgang.
@@ -303,7 +328,7 @@ Damit ist der schmale Streifen technisch schon da. Offen bleibt, ob er am Handy
 der **Standard** sein soll.
 
 
-**Der Zwiespalt:** Die App lädt die Leiste bei *jedem* Aufruf nach, also ist sie
+**Der Zwiespalt:** Die App lädt die HoneyBar bei *jedem* Aufruf nach, also ist sie
 immer da — auch wenn man die Cloud einfach direkt öffnet und mit
 HoneyOS gerade nichts zu tun hat. 32 px, dauerhaft, in einer App, die man auch
 für sich allein benutzt. Am Handy in einer installierten PWA wiegt das schwerer
@@ -313,18 +338,18 @@ Möglichkeiten, von viel nach wenig Platz:
 
 | | Platz | Gefühl |
 |---|---|---|
-| volle Leiste | 32 px immer | am ehesten „OS" |
+| volle HoneyBar | 32 px immer | am ehesten „OS" |
 | schmaler Streifen, klappt bei Berührung auf | 4 px | immer erreichbar, nie im Weg |
-| nur ein Eckknopf | ~0 | praktisch, aber keine Leiste mehr |
+| nur ein Eckknopf | ~0 | praktisch, aber keine HoneyBar mehr |
 | `data-push="none"` (liegt darüber) | 0 im Layout | verdeckt die Kopfzeile der App |
-| ganz aus | 0 | schon eingebaut („leiste ausblenden") |
+| ganz aus | 0 | schon eingebaut („honeybar ausblenden") |
 
-→ **Vorschlag: am Rechner die volle Leiste, am Handy der schmale Streifen.**
+→ **Vorschlag: am Rechner die volle HoneyBar, am Handy der schmale Streifen.**
 Als Einstellung, nicht fest verdrahtet — dann lässt sich die Meinung ändern,
 ohne etwas neu zu bauen.
 
 **Wichtig für die Entscheidung:** Das ist keine Einbahnstraße. In den Apps steht
-nur ein Ursprung in der `.env`; das Verhalten der Leiste liegt zentral in HoneyOS. Aussehen,
+nur ein Ursprung in der `.env`; das Verhalten der HoneyBar liegt zentral in HoneyOS. Aussehen,
 Höhe, Auto-Verstecken, Abschaffen — alles eine Änderung an einer Stelle, ohne
 Aether oder InkNote neu zu bauen.
 
@@ -335,13 +360,13 @@ in beide gleichzeitig.
 
 **Empfehlung: löschen.** Gründe:
 
-1. Er wirkt nur an einer von zwei Stellen — in der Leiste ja, auf dem Desktop
+1. Er wirkt nur an einer von zwei Stellen — in der HoneyBar ja, auf dem Desktop
    nie. Das ist schwer zu erklären und noch schwerer zu merken.
 2. Er bringt allein die Namensanzeige. Kein Funktionsunterschied.
 3. Sobald 1.3 gebaut ist, ist er ohnehin überflüssig.
 4. **Scharfe Kante:** Das Feld „Wer-bin-ich" darf auch eine vollständige fremde
    Adresse sein. Steht dort etwas Fremdes *und* ein Token-Schlüssel, schickt die
-   Leiste den InkNote-Token dorthin. Das setzt voraus, dass jemand Angemeldetes
+   HoneyBar den InkNote-Token dorthin. Das setzt voraus, dass jemand Angemeldetes
    das selbst einträgt — bei einer Ein-Personen-Instanz also kein akuter
    Notstand, aber eine Falle, die niemand braucht.
 
@@ -355,16 +380,16 @@ Heute gilt die App-Liste für alle — bewusst so, siehe „Bewusst nicht geplan
 Denkbar wäre daneben eine kleine eigene Liste je Konto.
 
 **Was dagegen spricht, ist nicht der Aufwand, sondern eine harte Grenze:** Auf
-dem Schreibtisch ginge es sofort (dort ist man angemeldet). In der Leiste einer
+dem Schreibtisch ginge es sofort (dort ist man angemeldet). In der HoneyBar einer
 fremden App ginge es **nicht**, solange HoneyOS auf einer anderen Site liegt als
 die App — der Browser schickt die HoneyOS-Sitzung dann nicht mit, und der
-Schlüssel für die App-Liste weiß nicht, wer schaut. Die Leiste zeigte also die
+Schlüssel für die App-Liste weiß nicht, wer schaut. Die HoneyBar zeigte also die
 gemeinsamen Apps, der Schreibtisch zusätzlich die eigenen. Zwei verschiedene
 Listen an zwei Stellen ist schlechter als eine.
 
 **Liegt alles unter derselben Domain** (`os.beispiel.duckdns.org` +
 `cloud.beispiel.duckdns.org`), fällt die Grenze weg: die Sitzung wird
-mitgeschickt, die Leiste weiß, wer da ist. Seit dem Umzug auf
+mitgeschickt, die HoneyBar weiß, wer da ist. Seit dem Umzug auf
 `os.asianxpolish.duckdns.org` ist genau das der Fall — persönliche Apps sind
 damit machbar geworden.
 
@@ -373,7 +398,7 @@ Person ist „persönlich" und „für alle" dasselbe. Der Weg ist aber offen un
 sollte es bleiben: nichts einbauen, was von einer einzigen gemeinsamen Liste
 ausgeht.
 
-### Wie weit soll das Aussehen der Leiste einstellbar sein?
+### Wie weit soll das Aussehen der HoneyBar einstellbar sein?
 
 Röhre, Leuchten und Scanlines kommen schon aus HoneyOS (1.1). Offen ist, was
 darüber hinaus in die Einstellungen gehört: Höhe, Schriftgröße, Position (oben
@@ -388,10 +413,10 @@ einmal ein und nie wieder — dann kann es auch gleich richtig fest stehen).
 
 `honeyos.duckdns.org` als Dach, die Apps darunter (`cloud.honeyos.duckdns.org`
 und so fort). Am 25.08.2026 gemessen: Dann schickt der Browser die
-HoneyOS-Sitzung an die Leiste mit, über eine fremde Site hinweg nicht.
+HoneyOS-Sitzung an die HoneyBar mit, über eine fremde Site hinweg nicht.
 
 Damit möglich, was heute nicht geht: **mehrere Nutzer mit eigenem Aussehen**,
-persönliche Apps, der Name in der Leiste. Und `HONEYBAR_KEY` samt CORS-Ausnahme
+persönliche Apps, der Name in der HoneyBar. Und `HONEYBAR_KEY` samt CORS-Ausnahme
 wird überflüssig — der Umzug räumt Komplexität weg, statt welche zu schaffen.
 
 Kosten sind einmalig, aber real: Redirect-URIs in PocketID, `PUBLIC_URL` und
@@ -417,7 +442,7 @@ Damit es nicht alle paar Monate neu diskutiert wird:
   (`helmet()`) verbieten es beide von sich aus, und das aus gutem Grund. Es
   würde Clickjacking-Schutz, PWA-Installierbarkeit und InkNotes Offline-Betrieb
   kosten. Widgets zeigen **Daten**, die Apps bleiben in ihrem eigenen Tab.
-- **Nichts über die Leiste wird beim Bauen der Apps eingebacken.** Die Adresse
+- **Nichts über die HoneyBar wird beim Bauen der Apps eingebacken.** Die Adresse
   stand einmal fest in Aethers `index.html`. Das war aus zwei Gründen falsch:
   Ein fertiges Abbild lässt sich dann nicht über die `.env` umziehen, und der
   Service Worker der PWA hält die alte `index.html` im Cache, so dass eine