Erst die Sitzung, dann der Schluessel

Der Schluessel kennt keinen Nutzer und landete beim Standardnutzer — auch
dann, wenn die App unter derselben Site liegt und der Browser das
HoneyOS-Cookie laengst mitschickt (cloud.honeyos.… und honeyos.… sind
dieselbe Site, duckdns.org steht auf der Public-Suffix-Liste). Damit trug
die HoneyBar in Aether die Farben eines fremden Nutzers.

Jetzt sieht /api/apps erst nach der Sitzung, und nur bei eigener
Anmeldung: Im offenen Betrieb und hinter einem Anmelde-Proxy gilt jede
Anfrage als angemeldet, dort bleibt der Schluessel das letzte Wort.
Test dazu, mit zwei Nutzern, damit der Rueckfall auf den einzigen Nutzer
das Ergebnis nicht zufaellig richtig aussehen laesst.

IDEAS.md

@@ -26,9 +26,11 @@ 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 HoneyBar die Farbe des
+Offen war: Bei mehreren Nutzern trägt die HoneyBar die Farbe des
 Standardnutzers, weil ihr über die Site-Grenze niemand sagen kann, wer da
-gerade schaut.
+gerade schaut. **Für Apps unter derselben Site erledigt seit dem 29.08.2026** —
+`/api/apps` sieht jetzt erst nach der Sitzung und erst dann nach dem Schlüssel.
+Über eine echte Site-Grenze bleibt es, wie es war.
 
 ### 1.2 Systemmenü im Logo — ✅ gebaut (29.08.2026)
 
@@ -153,8 +155,11 @@ Zwei Gründe, trotzdem mit der gemeinsamen anzufangen:
    Standardnutzers, während der Schreibtisch die eigene zeigt — derselbe Bruch
    wie heute bei den Farben.
 
-→ **Zusammen mit „Persönliche Apps je Nutzer" zu bauen, und beides hängt an
-derselben Bedingung: ein zweiter Nutzer oder alles unter einer Domain.**
+→ **Zusammen mit „Persönliche Apps je Nutzer" zu bauen.** Die Bedingung dafür
+ist am 29.08.2026 weggefallen: Aether und InkNote liegen längst unter
+`*.honeyos.duckdns.org`, also unter derselben Site, und `/api/apps` sieht seither
+erst nach der Sitzung. **Die HoneyBar weiß dort jetzt, wer schaut.** Was bleibt,
+ist die Frage, ob es sich bei einem Nutzer lohnt.
 
 ### 1.4 HoneyOS selbst als PWA
 
@@ -511,11 +516,11 @@ Schlüssel für die App-Liste weiß nicht, wer schaut. Die HoneyBar zeigte also
 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 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.
+**Liegt alles unter derselben Domain**, fällt die Grenze weg: die Sitzung wird
+mitgeschickt, die HoneyBar weiß, wer da ist. **Das ist seit dem 29.08.2026 der
+Fall** — Aether liegt unter `cloud.honeyos.duckdns.org`, HoneyOS unter
+`honeyos.duckdns.org`, und `/api/apps` sieht erst nach der Sitzung und dann
+erst nach dem Schlüssel. Persönliche Apps sind damit machbar geworden.
 
 → **Vorschlag: zurückstellen, bis es mehr als ein Konto gibt.** Bei einer
 Person ist „persönlich" und „für alle" dasselbe. Der Weg ist aber offen und