winbuild (VM 131) im Server-Netz: 10.10.2.131

Co-Authored-By: Eifelduds <noreply@eifelduds.de>

.gitea/workflows/release.yml

@@ -38,7 +38,7 @@ on:
 jobs:
   windows:
     name: Windows (MSI + NSIS)
-    # Label `windows` = act_runner auf der Build-VM winbuild (192.168.1.69),
+    # Label `windows` = act_runner auf der Build-VM winbuild (10.10.2.131, Server-Netz),
     # Win11, cargo 1.98.1, Node 24, Tauri-CLI 2.11.4. Laut Infrastruktur-Doku
     # on-demand — laeuft die VM nicht, wird der Job nie geplant (Gitea zeigt
     # dann gar keinen Lauf an, keinen fehlgeschlagenen).

docs/tauri-release.md

@@ -304,7 +304,7 @@ Linux** automatisch. Trigger ist ein Tag `v*.*.*` (zusätzlich manuell per
 
 | Job | `runs-on` | Runner | Bundles |
 |---|---|---|---|
-| `windows` | `windows` | winbuild, 192.168.1.69 (on-demand) | `msi/*.msi`, `nsis/*-setup.exe` |
+| `windows` | `windows` | winbuild, 10.10.2.131 (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