Automate GitHub Release creation in the release workflow via gh CLI

The gh CLI is now installed and authenticated (see gh auth status),
so future releases create the GitHub Release and upload the firmware
binary automatically instead of leaving that as a manual step.

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

CLAUDE.md

@@ -194,26 +194,23 @@ in dieser Reihenfolge:
 6. Alle diese Änderungen (Code + README + Web-Flasher-Dateien) zusammen
    committen und pushen (`git push`, plus `git push origin vX.Y.Z` falls ein
    Tag erstellt wurde).
-7. Kurze Zusammenfassung am Ende: was committet/getaggt/gepusht wurde, und
+7. ERST DANACH (nach Schritt 5, wenn bootloader/firmware/partitions bereits
-   ob die README aktualisiert wurde (und falls ja, welche Abschnitte).
-8. ERST DANACH (nach Schritt 5, wenn bootloader/firmware/partitions bereits
    ins Hauptverzeichnis kopiert sind): die `firmware.bin` im
    `.pio/build/esp32dev/`-Ordner zusätzlich zu `CYD-flightradar.bin`
    umbenennen (bzw. kopieren) - das ist die Datei für den GitHub-Release-
-   Upload, erspart das manuelle Umbenennen nach jedem Release. WICHTIG:
+   Upload. WICHTIG: diese Umbenennung darf NICHT vor dem Auto-Flash (siehe
-   diese Umbenennung darf NICHT vor dem Auto-Flash (siehe unten) passieren,
+   unten) passieren, sonst schlägt `pio run --target upload` fehl, weil es
-   sonst schlägt `pio run --target upload` fehl, weil es die Datei unter
+   die Datei unter dem Namen `firmware.bin` erwartet.
-   dem Namen `firmware.bin` erwartet.
 
    SICHERHEITSPROBLEM bei dieser Umbenennung: Falls im
    `.pio/build/esp32dev/`-Ordner bereits eine `CYD-flightradar.bin` von
-   einem vorherigen Release liegt (weil Alex vergessen hat, sie nach dem
+   einem vorherigen Release liegt (weil sie nach dem letzten Release aus
-   Release manuell zu löschen), darf das Umbenennen NICHT einfach
+   irgendeinem Grund nicht geloescht wurde), darf das Umbenennen NICHT
-   übersprungen werden (z.B. weil ein `mv`/Kopiervorgang auf eine bereits
+   einfach übersprungen werden (z.B. weil ein `mv`/Kopiervorgang auf eine
-   existierende Zieldatei fehlschlägt oder stillschweigend nichts tut) -
+   bereits existierende Zieldatei fehlschlägt oder stillschweigend nichts
-   sonst verwendet Alex beim nächsten GitHub-Release versehentlich die
+   tut) - sonst würde beim GitHub-Release versehentlich die ALTE,
-   ALTE, veraltete `CYD-flightradar.bin`, obwohl der frisch gebaute Code
+   veraltete `CYD-flightradar.bin` hochgeladen, obwohl der frisch gebaute
-   neuer ist. Das ist ein ernsthaftes Risiko (veraltete Firmware wird
+   Code neuer ist. Das ist ein ernsthaftes Risiko (veraltete Firmware wird
    veröffentlicht, ohne dass es auffällt). Deshalb bei JEDEM Release als
    expliziter, nicht überspringbarer Schritt:
    a) Prüfen, ob im `.pio/build/esp32dev/`-Ordner bereits eine Datei
@@ -224,9 +221,30 @@ in dieser Reihenfolge:
    c) Danach die aktuelle `firmware.bin` zu `CYD-flightradar.bin`
       umbenennen (wie oben beschrieben).
    d) Am Ende der Release-Zusammenfassung IMMER explizit erwähnen, ob eine
-      alte `CYD-flightradar.bin` gefunden und gelöscht wurde, damit Alex
+      alte `CYD-flightradar.bin` gefunden und gelöscht wurde.
-      das mitbekommt (z.B. "Hinweis: eine alte CYD-flightradar.bin lag
+8. GitHub Release erstellen UND die `.bin`-Datei in einem Schritt hochladen
-      noch im Ordner und wurde vor dem Umbenennen gelöscht").
+   (per `gh` CLI, seit v2.7.5 eingerichtet und authentifiziert - siehe
+   `gh auth status`):
+
+       gh release create vX.Y.Z .pio/build/esp32dev/CYD-flightradar.bin \
+           --repo Eiswolf-BG/eiswolfs-flightradar-CYD \
+           --title "vX.Y.Z" \
+           --notes "<Release-Notes-Text>"
+
+   Der Release-Notes-Text kommt aus dem jeweiligen Push-Wunsch (derselbe
+   Text, der auch für die Tag-Message verwendet wird) - falls im
+   Push-Wunsch kein Text mitgegeben wurde, aus dem `git log` seit dem
+   letzten Tag ableiten, wie bisher auch für die Tag-Message.
+9. Nach erfolgreichem Upload: die lokale Kopie
+   `.pio/build/esp32dev/CYD-flightradar.bin` wieder löschen - reines
+   Build-Artefakt fürs Hochladen, gehört nicht ins Repo und wird nicht
+   committet.
+10. Kurze Zusammenfassung am Ende: was committet/getaggt/gepusht wurde, ob
+    die README aktualisiert wurde (und falls ja, welche Abschnitte), sowie
+    die URL des erstellten GitHub Release. Der GitHub-Release-Schritt ist
+    damit vollautomatisch - kein manuelles Nacharbeiten von Alex mehr
+    nötig, außer `gh` sollte einmal die Authentifizierung verlieren (dann
+    erneut `gh auth login`, siehe oben).
 
 ## Nach jedem erfolgreichen Build automatisch flashen