refactor: Build-Upload nutzt SECRET_KEY + Doku klargestellt

- Backend: Upload-Auth prueft SECRET_KEY statt eigenen Token
  (ein Token weniger zu verwalten)
- BUILD_UPLOAD_TOKEN in Entwicklungs-.env = SECRET_KEY vom Server
- .env.example: Klarer Kommentar dass CLOUD_URL + BUILD_UPLOAD_TOKEN
  NUR auf der Entwicklungsmaschine gesetzt werden, nicht auf dem Server
- README: Desktop Sync Client Abschnitt mit Build-Anleitung und
  Auto-Upload-Erklaerung

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.env.example

@@ -36,9 +36,12 @@ MAX_UPLOAD_SIZE_MB=500
 # JWT wird automatisch vom JWT_SECRET_KEY oben verwendet
 ONLYOFFICE_URL=
 
-# Client-Downloads (optional)
-# Oeffentliche URL der Cloud-Instanz (fuer den Build-Upload)
+# =============================================
+# Client-Build Upload (NUR auf der Entwicklungsmaschine!)
+# Diese Werte gehoeren NICHT auf den Produktionsserver,
+# sondern in die .env der Maschine auf der ./build.sh laeuft.
+# =============================================
+# Oeffentliche URL der Cloud-Instanz wohin die Builds hochgeladen werden
 CLOUD_URL=https://cloud.example.com
-# Token fuer Build-Upload (gleicher wie SECRET_KEY oder eigener)
-# Token generieren: python3 -c "import secrets; print(secrets.token_urlsafe(64))"
+# SECRET_KEY des Zielservers (identisch mit SECRET_KEY oben auf dem Server)
 BUILD_UPLOAD_TOKEN=