Releases des Forks für Nutzer ohne Checkout #38

Der Fork lässt sich heute nur aus einem git-Checkout nutzen (fork-app.sh prepare, prepare-server, LaunchAgent-Umbau aus docs/fork/setup.md). Ziel: Wer nur die App herunterlädt, bekommt fertige Releases und Updates, ohne Node, pnpm oder Rust.

Mögliches Vorgehen

• release.yml / release-desktop.yml für esveo/t3code lauffähig machen, am besten als eigener Fork-Workflow in einer neuen Datei statt Änderungen quer durch upstreams Workflows.
• Desktop-Updater und t3 update auf die Releases des Forks zeigen lassen statt auf pingdotgg/t3code, möglichst über eine Build-Variable statt über Code-Änderungen.
• App und Server immer gemeinsam veröffentlichen, damit die Fork-App nie gegen einen Release-Server von upstream läuft.
• Eigenes Versionsschema, z. B. <upstream-version>-esveo.<n>, das sich nicht mit upstream-Versionen überschneidet und für den Updater trotzdem korrekt sortiert.

Absehbare Probleme

• Signierung: Ohne Apple Developer Program (99 €/Jahr) keine Notarisierung, Gatekeeper-Warnung beim Start, und Squirrel.Mac installiert keine Auto-Updates. Windows zeigt ohne Zertifikat eine SmartScreen-Warnung. Wird separat entschieden.
• Cloud-Konfiguration: Upstream bettet Relay-URL, Clerk-Key und CLI-OAuth-Client beim Build ein. Die Fork-Builds bräuchten eigene oder dieselben Werte; ob T3 Connect mit Fork-Builds offiziell funktionieren darf, ist offen.
• Hintergrunddienst: Der LaunchAgent zeigt auf die Release-Runtime. Eine heruntergeladene Fork-App müsste den Dienst selbst auf den Fork-Server umstellen, inklusive Launcher-Protokoll (SERVICE_LAUNCHER_PROTOCOL), sonst Crash-Loop wie in setup.md beschrieben.
• Konflikt mit einer upstream-Installation: Beide teilen sich ~/.t3 und den t3-Dienst. Entweder klar ersetzen oder eigenes Home und eigenen Dienstnamen verwenden.
• Merge-Kosten: Updater-Feed, Versionierung und Release-Pipeline sind upstream-Dateien, die sich oft ändern. Jede Anpassung dort ist ein wiederkehrender Konflikt beim täglichen Upstream-Sync.
• Mobile: App Store und Google Play sind für den Fork kaum sinnvoll; mobile Clients würden gegen Fork-Server mit Zusatzfunktionen laufen, die sie nicht kennen.
• Release-Takt: Upstream kommt täglich über den Sync rein. Ob jeder Merge in fork ein Release wird oder nur ausgewählte Stände, muss entschieden werden.
• CI-Kosten: Upstream baut auf Blacksmith-Runnern; auf normalen GitHub-Runnern sind macOS-Builds langsam und teuer.