ci: Release-Workflow für den Desktop-Client

Das Repo hatte keine CI. Der Workflow folgt dem Muster, das im
Nachbarprojekt lserver produktiv läuft: Tag v*.*.* baut, lädt die
Bundles als Artefakte hoch und hängt sie an ein Gitea-Release.

Zwei Jobs. Windows läuft auf dem Runner-Label `windows` (VM 131
winbuild) und liefert MSI und NSIS. Linux läuft bewusst NICHT auf
`ubuntu-latest`: auf diesem Runner ist das Label auf
docker://node:22-bookworm gemappt, also einen Container mit Node, aber
ohne Rust und ohne GTK — der Job wäre bei cargo abgebrochen.
Nachgesehen in /var/lib/gitea-runner/.runner. Das Host-Label heißt
linux-amd64 und hat die vollständige Toolchain.

macOS hat keinen Runner; der Weg für lokale .dmg-Builds steht als
Kommentar im Workflow und in docs/tauri-release.md.

AppImage ist ein eigener Schritt mit continue-on-error, weil es laut
Infrastruktur-Doku an linuxdeploy/FUSE scheitert — deb und rpm sollen
davon nicht mitgerissen werden. APPIMAGE_EXTRACT_AND_RUN und NO_STRIP
sind gesetzt, patchelf war auf dem Runner nicht installiert und wurde
nachgezogen.

Vermerkt ist auch die Falle, die lserver einen Tag CI gekostet hat:
sobald .gitea/workflows/ existiert, ignoriert Gitea .github/workflows/
vollständig — ohne roten Lauf, einfach still.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013HC9HLrUU1LNwkzp8nkDLX

docs/tauri-release.md

@@ -296,13 +296,57 @@ beiden.
 5. Mit einer älteren installierten Version gegenprüfen, dass `check()` das
    Update findet und die Signaturprüfung durchgeht.
 
-## 8. Offene Punkte
+## 8. CI: Tag-Release über Gitea Actions
+
+`.gitea/workflows/release.yml` baut Schritt 2 der Checkliste für **Windows und
+Linux** automatisch. Trigger ist ein Tag `v*.*.*` (zusätzlich manuell per
+`workflow_dispatch`, dann ohne Release-Anlage).
+
+| Job | `runs-on` | Runner | Bundles |
+|---|---|---|---|
+| `windows` | `windows` | winbuild, 192.168.1.69 (on-demand) | `msi/*.msi`, `nsis/*-setup.exe` |
+| `linux` | `ubuntu-latest` | ci-runner, 192.168.1.72 | `deb/*.deb`, `rpm/*.rpm`, `appimage/*.AppImage` |
+
+Beide Jobs laufen `npm ci` (es gibt eine `package-lock.json`) und danach den
+npm-Skript-Umweg `npm run tauri -- build --ci` aus `crates/tauri-app/`, damit
+die im Lock gepinnte `@tauri-apps/cli` benutzt wird und nicht die zufällig auf
+dem Runner installierte. Die Pfade sind die aus Abschnitt 5. Beide laden ihre
+Bundles als Job-Artefakt hoch **und** hängen sie an dasselbe Gitea-Release zum
+Tag (anlegen, und falls der andere Job schneller war, das vorhandene per Tag
+holen). Die Release-Beschreibung kommt aus dem passenden
+`## [<version>]`-Abschnitt einer `CHANGELOG.md`, sobald es eine gibt — bis
+dahin steht dort der Commit-SHA.
+
+Zwei Dinge, die der Workflow *nicht* tut:
+
+* **macOS.** Es gibt keinen macOS-Runner. `.dmg`/`.app` werden lokal nach
+  Abschnitt 4 gebaut und im Gitea-Release von Hand angehängt.
+* **Signierte Updater-Artefakte.** Der Workflow baut ohne Release-Overlay und
+  ohne `TAURI_SIGNING_PRIVATE_KEY*`; es entstehen also keine `.sig`-Dateien
+  (Abschnitt 2 und 5). Für ein echtes Auto-Update müssen Overlay-Datei und
+  Secrets ergänzt und der Build-Aufruf um
+  `--config src-tauri/tauri.release.conf.json` erweitert werden.
+
+**Vor dem Tag zu bumpen** (Schritt 1 der Checkliste): Die Release-Version kommt
+aus dem Tag, die Version im *Dateinamen* aus `src-tauri/tauri.conf.json`. Ohne
+Bump heißt das Artefakt zu `v0.2.0` weiterhin
+`maarcadetweet_0.1.0_x64-setup.exe`. `src-tauri/Cargo.toml` und `package.json`
+mitziehen — alle drei stehen aktuell auf `0.1.0`.
+
+> **Falle:** Sobald `.gitea/workflows/` existiert, ignoriert Gitea
+> `.github/workflows/` vollständig — kommentarlos, ohne roten Lauf. Im
+> Nachbarprojekt `lserver` waren Tests dadurch einen Tag lang still
+> abgeschaltet. Dieses Repo hat kein `.github/`, und das soll so bleiben: neue
+> Workflows gehören nach `.gitea/workflows/`.
+
+## 9. Offene Punkte
 
 * Kein Release-Overlay im Repo — die Datei aus Abschnitt 2 muss angelegt
   werden. Der Endpoint `https://releases.maarcadetweet.local/…` in der aktuellen
   Config ist ein Platzhalter und existiert nicht.
-* Kein Update-Server, kein CI-Workflow, kein Skript, das `latest.json` erzeugt
-  (`scripts/` ist leer).
+* Kein Update-Server und kein Skript, das `latest.json` erzeugt (`scripts/` ist
+  leer). Der CI-Workflow aus Abschnitt 8 baut und veröffentlicht Installer,
+  aber keine Updater-Artefakte.
 * Keine Code-Signierung/Notarisierung für macOS und keine Authenticode-Signatur
   für Windows konfiguriert (`bundle` enthält weder `macOS.signingIdentity` noch
   `windows.certificateThumbprint`). Der Tauri-Updater-Schlüssel ersetzt das