Der Notifier weckt nur noch, wenn wirklich etwas anliegt

Andreas: "koennen wir da nicht noch einbauen das der nur feuert wenn
tatsaechlich was anliegt? das wuerde ich nicht dem client ueberlassen
sondern schon im notifier loesen. der mail notifier muss doch auch sowas
machen." Richtig -- und der Vergleich trifft den Kern: goimapnotify hat
das Problem nicht, weil IMAP IDLE ein echtes Ereignis liefert. Bei
Mattermost fehlt der Push fuer Kanaele, und mein Boden hat das mit
blindem Feuern ausgeglichen.

Jetzt sieht der Boden selbst nach: je Kanal ein posts?since=<marke>, das
bei Stille leer zurueckkommt. Eigene Beitraege und system-Ereignisse
zaehlen nicht, sonst loeste die eigene Antwort den naechsten Durchgang
aus. Ein Dutzend Kanaele bei 60 s Takt sind zwoelf Anfragen pro Minute --
gegen einen Modelllauf ist das nichts.

Der Weg dahin war laenger als noetig, weil drei Mattermost-Felder auf
dieser Instanz luegen: last_post_at blieb nach einem neuen Beitrag
unveraendert, msg_count zaehlte weiter obwohl der Kanal als gesehen galt,
und last_viewed_at war neuer als die ungelesenen Beitraege. posts?since=
ist das einzige, das nachweislich stimmt.

Gemessen: zwei Durchgaenge Stille ohne einen einzigen Aufruf des
Befehls, dann ein fremder Beitrag -> gefeuert. Genau das Verhalten von
goimapnotify.

README.md

@@ -101,6 +101,37 @@ Weigert sich der Server, wird das protokolliert und weitergearbeitet: Ein Agent,
 der aufhört zu antworten, weil er einen Punkt nicht einfärben konnte, wäre
 absurd.
 
+## Der Türsteher vor dem teuren Teil
+
+`mmnotify` weckt **nur, wenn wirklich etwas anliegt** — auch beim Boden. Das ist
+keine Bequemlichkeit für den Aufrufer, sondern der Sinn eines Notifiers: Hinter
+`on_mention` hängt in der Regel ein Sprachmodell, und ein Boden, der blind
+feuert, lässt es rund um die Uhr laufen. Bei vier Agenten und 15 Sekunden Takt
+waren das 16 Modellläufe pro Minute, ohne dass jemand geschrieben hatte.
+
+`goimapnotify` hat dieses Problem nicht, weil IMAP IDLE ein echtes Ereignis
+liefert. Bei Mattermost fehlt der Push für Kanäle, also muss der Notifier
+selbst nachsehen — und zwar so:
+
+- Je Kanal ein `posts?since=<marke>`. Bei Stille kommt eine leere Liste zurück.
+  Ein Dutzend Kanäle bei 60 s Takt sind zwölf Anfragen pro Minute; gegen einen
+  Modelllauf ist das nichts.
+- Eigene Beiträge und `system_*`-Ereignisse zählen nicht — sonst löste die
+  eigene Antwort den nächsten Durchgang aus.
+- Beim Start wird der Ausgangsstand gesetzt, mit zwei Minuten Rückgriff: Was
+  unmittelbar vor dem Start eintraf, geht nicht verloren, aber es wird auch
+  nicht für die halbe Kanalgeschichte geweckt.
+
+**Nicht** über `last_post_at`, `msg_count` oder `last_viewed_at`: Auf alle drei
+war auf der getesteten Instanz kein Verlass — `last_post_at` blieb nach einem
+neuen Beitrag unverändert, `msg_count` zählte weiter, obwohl der Kanal als
+gesehen galt, und `last_viewed_at` war neuer als die ungelesenen Beiträge.
+`posts?since=` ist das einzige Feld, das nachweislich stimmt.
+
+Gelesen wird der Beitrag dabei nicht. Der Türsteher fragt „gibt es etwas?",
+nicht „was steht drin" — das bleibt beim Agenten, sonst gäbe es zwei Leser und
+zwei Antworten.
+
 ## Robustheit
 
 - Wiederaufbau mit wachsendem Abstand (1 s bis 60 s). Ein Server, der neu