Fix OTA download (follow GitHub redirect), rework result screens, drop asset rename

OTA downloads always failed because GitHub's browser_download_url
returns a 301/302 redirect to a signed objects.githubusercontent.com
URL, which HTTPUpdate doesn't follow by default. Now sets
HTTPC_STRICT_FOLLOW_REDIRECTS before downloading.

Update results (success and failure) are now shown as a persistent
info screen requiring an explicit tap to dismiss, instead of a
1.2-1.5s auto-vanishing message followed by an automatic restart -
a firmware update result is important enough that it shouldn't be
missable. Also fixes long dynamic titles (e.g. "Update available:
v3.5.0") and the installing-progress label overflowing the screen
edge in some languages.

Release workflow no longer renames the build artifact to
CYD-flightradar.bin before upload; the release asset is just
firmware.bin now, matching what OtaUpdate::checkForUpdate() looks
for. CLAUDE.md's release workflow updated to match.

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

CLAUDE.md

@@ -213,39 +213,15 @@ 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. 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. WICHTIG: diese Umbenennung darf NICHT vor dem Auto-Flash (siehe
-   unten) passieren, sonst schlägt `pio run --target upload` fehl, weil es
-   die Datei unter 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 sie nach dem letzten Release aus
-   irgendeinem Grund nicht geloescht wurde), darf das Umbenennen NICHT
-   einfach übersprungen werden (z.B. weil ein `mv`/Kopiervorgang auf eine
-   bereits existierende Zieldatei fehlschlägt oder stillschweigend nichts
-   tut) - sonst würde beim GitHub-Release versehentlich die ALTE,
-   veraltete `CYD-flightradar.bin` hochgeladen, obwohl der frisch gebaute
-   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
-      namens `CYD-flightradar.bin` existiert.
-   b) Falls ja: diese alte Datei IMMER ZUERST LÖSCHEN, bevor die aktuelle
-      `firmware.bin` umbenannt wird (nicht überspringen, nicht
-      stillschweigend stehen lassen).
-   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.
-8. GitHub Release erstellen UND die `.bin`-Datei in einem Schritt hochladen
+7. GitHub Release erstellen UND die `.bin`-Datei in einem Schritt hochladen
    (per `gh` CLI, seit v2.7.5 eingerichtet und authentifiziert - siehe
-   `gh auth status`):
+   `gh auth status`). Das Release-Asset heißt einfach `firmware.bin`, keine
+   Umbenennung nötig - die meisten Nutzer laden ohnehin über den
+   Web-Flasher, das Asset ist nur noch für die wenigen Leute relevant, die
+   über eine CYD-Launcher-App direkt eine `.bin`-Datei brauchen (dafür ist
+   der Dateiname egal):
 
-       gh release create vX.Y.Z .pio/build/esp32dev/CYD-flightradar.bin \
+       gh release create vX.Y.Z .pio/build/esp32dev/firmware.bin \
            --repo Eiswolf-BG/eiswolfs-flightradar-CYD \
            --title "vX.Y.Z" \
            --notes "<Release-Notes-Text>"
@@ -254,16 +230,12 @@ in dieser Reihenfolge:
    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).
+8. 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