docs: durchgaengig ID statt Kennung

In der Oberflaeche hiess das Feld Kennung, in der Konfiguration id, in der
README beides. Drei Namen fuer dieselbe Sache, und man muss sie beim Eintragen
zusammenbringen — jetzt ueberall ID.

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

README.md

@@ -104,7 +104,7 @@ entfällt der Schlüssel und alles funktioniert ohne Einschränkung.
 
 | Feld | wofür |
 |---|---|
-| Kennung | klein, ohne Leerzeichen — muss zu `data-app` der Leiste passen |
+| ID | klein, ohne Leerzeichen — muss zu `data-app` der Leiste passen |
 | Name, Untertitel | Beschriftung auf Kachel und Symbol |
 | Adresse | wohin der Start springt |
 | Symbol | cloud · note · box · chip · folder · gear · globe · disk |
@@ -191,7 +191,7 @@ HTML geschrieben wird, lässt sich hinterher nicht mehr ändern. Und der Service
 Worker einer PWA hebt ganze Antworten auf, samt Kopfzeilen; eine ins HTML
 eingefrorene Adresse überlebt dort jede Konfigurationsänderung.
 
-`data-app` ist die Kennung aus der App-Liste. Die Liste holt sich die Leiste selbst von
+`data-app` ist die ID aus der App-Liste. Die Liste holt sich die Leiste selbst von
 `/api/apps` — mit deiner HoneyOS-Sitzung, weil alle Adressen unter derselben Domain liegen.
 **Freigegeben sind nur die Ursprünge, die selbst als App eingetragen sind**: die App-Liste
 ist zugleich ihre eigene CORS-Freigabe.
@@ -346,7 +346,7 @@ Nicht viel, aber nicht nichts:
   Einsetzer für beliebig viele Dienste in einem Stapel.** Zwei Tabellen oben in
   der Datei sagen, welcher Name zu welchem Behälter gehört und welche App das
   für HoneyOS ist; eine neue App sind zwei Zeilen. Die Leiste hebt die aktuelle
-  App hervor, sobald `$appid` der `id` in der App-Liste entspricht — genau wie
+  App hervor, sobald `$appid` der `ID` in der App-Liste entspricht — genau wie
   in Aether und InkNote. Am Host erkennt nginx, welcher
   Dienst gemeint ist; eine neue App sind zwei Zeilen in den Tabellen oben in
   `leiste.conf`. Das ist der Aufbau, den man haben will, sobald es mehr als ein