feat(update): App laedt Updates per HTTP mit Fortschrittsanzeige statt als 65-MB-WebSocket-Block

Bisher kam die APK als EINE WebSocket-Nachricht (~65 MB Base64) mit starrem
60-s-Timeout — ueber den externen Proxy (Heim-Upload → Hetzner → Handy) zu
knapp, Abbruch ohne Fortschritt.

RVS: GET/HEAD /update/latest.apk — nur mit gueltigem Raum-Token im Header
X-RVS-Token (sonst 403), Content-Length, Range/206 zum Fortsetzen. Version
im Dateinamen wird ohne angehaengten Punkt erkannt.

App: Download per HTTP (react-native-fs) mit Fortschritt in % und MB,
Abbrechen-Knopf, Abbruch nur bei 30 s ohne Daten statt fester Gesamtzeit,
3 Versuche, Groessen-Check gegen Content-Length. Alter RVS (404): Fallback
auf den WebSocket-Weg mit 5 min Timeout.

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

README.md

@@ -855,7 +855,9 @@ Satelliten verbinden dann nicht mehr). ACME-State persistent in `./data/caddy/`
 - WebSocket Relay (alle Message-Types: chat, audio, file, config, xtts, update, etc.)
 - OAuth-Callback HTTP: `GET /oauth/callback/{service}?code=...` → broadcastet als
   `oauth_callback`-WS-Message + zeigt dem Browser eine "OAuth erfolgreich"-Seite
-- Auto-Update: APK-Verteilung an Apps ueber WebSocket
+- Auto-Update: App fragt per WebSocket nach der Version, laedt die APK per HTTP
+  (`/update/latest.apk`, nur mit gueltigem Raum-Token im Header `X-RVS-Token`,
+  mit Fortschrittsanzeige + Fortsetzen per Range). Alte Apps: Fallback ueber WebSocket
 - Heartbeat + tote Verbindungen aufraeumen
 
 **Auto-Update APK bereitstellen:**