docs: IDEAS.md angelegt; Abo-Link und Aufgabenansicht vertagt

Beide haben einen guten Grund, aber keinen Anlass -- und eine Funktion ohne
Anlass zu bauen ist der Weg, auf dem eine Anwendung unuebersichtlich wird.
Die Ueberlegungen stehen samt dem, was daran nicht trivial ist, in IDEAS.md
statt verloren zu gehen.

Beim Abo-Link sind das drei Dinge: nur lesend ohne Ausnahme; ein Schalter
"nur Belegt/Frei", weil ein Abo sonst jeden Termintitel mitgibt; und dass
ein Abo regelmaessig von einer Maschine abgerufen wird -- Zaehler und
Fehlversuchssperre der Datei-Freigabelinks passen darauf nicht.

Dazu ein Widerspruch, der beim Nachsehen auffiel: "Kalender in der
HoneyOS-Leiste" steht seit dem ersten Entwurf in Phase 4, aber HoneyOS hat
sich am 29.08.2026 ausdruecklich gegen Widgets entschieden, die Daten aus
Aether oder InkNote holen. Der technische Grund dafuer ist inzwischen weg
(gleiche Domain), der inhaltliche nicht. Das gehoert entschieden, nicht
gebaut -- deshalb im Plan vermerkt statt umgesetzt.

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

kalender-plan.md

@@ -86,7 +86,7 @@ Die abgeleiteten Spalten sind nur zum Vorsortieren da.
 | **1** | CalDAV lesend und schreibend, ein Kalender, Anmeldung über App-Passwörter, Auffindpfade (`/.well-known/caldav`, `current-user-principal`, `calendar-home-set`). Ziel: DAVx5 gleicht ab. | ✅ |
 | **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | ✅ |
 | **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | ✅ |
-| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅, Aufgabenansicht (vertagt), öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | läuft |
+| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅. Aufgabenansicht und Abo-Link vertagt → [IDEAS.md](IDEAS.md). Kalender in der HoneyOS-Leiste: **widerspricht einer Entscheidung in HoneyOS**, siehe unten. | im Wesentlichen erledigt |
 | **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden |
 
 Über die Phasen hinaus dazugekommen, weil es sich beim Prüfen als nötig
@@ -193,12 +193,37 @@ Fall, auf den es ankommt: *ohne Änderung kommt nichts zurück*.
    vorher nichts sieht – ohne diesen Anfang beweist der Rest nichts.
 3. **Ein Kalender an der Adresse eines Links**, den jemand ohne Konto
    abonnieren kann – nur lesend, wie ein Freigabelink für Dateien. Klein, und
-   Aether hat die Freigabelinks schon. **Phase 4.**
+   Aether hat die Freigabelinks schon. **Vertagt am 12.09.2026** – kein Anlass,
+   solange es nur ein Konto gibt. Die Überlegung samt der drei Dinge, die daran
+   nicht trivial sind, steht in [IDEAS.md](IDEAS.md).
 
 Was **nicht** kommt: Einladungen per E-Mail (iMIP/iTIP) und Frei/Belegt-Abfragen
 über Serviergrenzen hinweg. Das ist der Teil, an dem Groupware groß und
 kompliziert wird – und der einzige, der wirklich wehtut.
 
+## Kalender in der HoneyOS-Leiste – steht im Widerspruch
+
+Der Punkt steht seit dem ersten Entwurf in Phase 4. Beim Nachsehen am
+12.09.2026 stellte sich heraus: **HoneyOS hat sich am 29.08.2026 dagegen
+entschieden.** In `honey-os/IDEAS.md`, Abschnitt „Bewusst nicht geplant":
+
+> **Keine Widgets, die Daten aus Aether oder InkNote holen** (gestrichen
+> 29.08.2026). […] der Weg über den HoneyBar-Proxy zeigt HoneyOS in den Apps,
+> statt die Apps in HoneyOS nachzubauen.
+
+Dazu die Grenze, die dort gezogen wurde: *„Nichts, was in einer App lebt, darf
+hier ein zweites Zuhause bekommen."*
+
+Zwei Pläne, zwei Richtungen – das gehört entschieden, nicht gebaut. Zur
+Vollständigkeit, was sich seither geändert hat: Der **technische** Grund ist
+weg. Seit dem 29.08.2026 liegen Aether und HoneyOS unter derselben Domain, die
+Sitzung wird also mitgeschickt; die Leiste läuft ohnehin *in* Aethers Seite und
+könnte den Kalender dort gleichursprünglich abfragen, ohne CORS und ohne einen
+zweiten Schlüssel. Übrig bleibt der **inhaltliche** Grund, und der ist der
+eigentliche: Soll der Schreibtisch Inhalte der Apps zeigen oder nicht?
+
+Solange das offen ist, bleibt der Punkt hier stehen und wird nicht gebaut.
+
 ## Felder – was ein Termin mitbringt
 
 Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern