ci: Gitea-Actions-Workflow für SemVer-Release-Builds

Bei push eines Tags v*.*.* wird ein statisches musl-Binary gebaut und als
Gitea-Release veröffentlicht (Asset + .sha256, Notes aus Commits). Suffix-Tags
(v1.2.3-rc1) werden als Pre-Release markiert; Cargo-Version wird an den Tag
angeglichen. README um Releases-Abschnitt ergänzt.

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

README.md

@@ -78,6 +78,26 @@ Systemweit installieren (nach `~/.cargo/bin`):
 cargo install --path .
 ```
 
+## Releases (Gitea Actions)
+
+Der Workflow `.gitea/workflows/release.yaml` baut bei einem **SemVer-Tag** ein statisches
+musl-Binary und veröffentlicht es als Release-Asset (inkl. `.sha256` und auto-generierten
+Release-Notes aus den Commits seit dem letzten Tag).
+
+```bash
+# nach SemVer taggen und pushen — das löst den Build + Release aus:
+git tag v0.1.0
+git push origin v0.1.0
+```
+
+Tags mit Suffix (`v1.2.3-rc1`) werden automatisch als **Pre-Release** markiert. Die Paketversion
+in `Cargo.toml` wird im Build an den Tag angeglichen, sodass `iroh-forward --version` passt.
+
+**Voraussetzungen:** In den Repo-Einstellungen müssen *Actions* aktiviert und ein
+[`act_runner`](https://docs.gitea.com/usage/actions/act-runner) registriert sein. Der Workflow nutzt
+den automatischen `GITHUB_TOKEN`; falls dieser keine Release-Schreibrechte hat, ein Repo-Secret
+`RELEASE_TOKEN` (Personal Access Token mit `write:repository`) anlegen.
+
 ### Statisches Binary fürs Deployment (optional)
 
 Für ein weitgehend abhängigkeitsfreies Binary, das auf jedem Linux-Host ohne passende glibc läuft,