Versionshinweis mit Aenderungsverlauf

Bisher liess sich der laufenden Anwendung nicht ansehen, welche Fassung sie
ist. Nach einem Update war damit auch nicht zu erkennen, ob es angekommen
ist — die haeufigste Frage im Betrieb.

Die Fussleiste nennt jetzt die Version und fuehrt auf /version mit dem
vollstaendigen Verlauf. Zusammengetragen ist er aus dem, was es schon gab:
dem Abschnitt „Gebaut" der Roadmap und der Git-Historie.

Gepflegt wird der Verlauf an genau einer Stelle, src/lib/changelog.ts. Daraus
entsteht sowohl die Seite als auch die CHANGELOG.md (npm run changelog); eine
Pruefung mit --check wacht darueber, dass beides zusammenpasst. Zwei gepflegte
Listen liefen unweigerlich auseinander, und ein Changelog, der nicht stimmt,
ist schlimmer als keiner.

Die Historie hatte keine Tags. Die Eintraege sind deshalb nach Erscheinungstag
zu Versionen zusammengefasst — die Nummern sind nachtraeglich vergeben, die
Daten stammen aus den Commits. Zu jeder Version gibt es jetzt einen
annotierten Tag im Repo; v1.6.0 folgt beim Merge.

Die Roadmap fuehrt den Verlauf nicht mehr doppelt, sondern verweist darauf und
behaelt den Blick nach vorn.

Refs #9

docs/funktionen.md

@@ -500,6 +500,21 @@ alles zeigt und Typen aus späteren Versionen automatisch erscheinen.
 
 ---
 
+## Version und Änderungen
+
+Die Fußzeile nennt die laufende Version und führt auf eine Seite mit dem
+vollständigen Änderungsverlauf. Nach einem Update ist das die schnellste
+Antwort auf die Frage, ob der Container wirklich mit dem neuen Abbild läuft:
+Steht dort noch die alte Nummer, ist er es nicht.
+
+Der Verlauf wird an **einer** Stelle gepflegt (`src/lib/changelog.ts`).
+Daraus entstehen sowohl die Seite in der Anwendung als auch die
+[CHANGELOG.md](../CHANGELOG.md) im Projekt (`npm run changelog`); eine
+Prüfung wacht darüber, dass beides zusammenpasst. Zu jeder Version gibt es
+einen Git-Tag.
+
+---
+
 ## Schnittstelle
 
 Alles, was die Oberfläche tut, geht auch über HTTP: