fix(release): bun statt npm-Fallback für Release-Builds erzwingen

make ui fällt ohne bun still auf npm install zurück — löst Dependencies
gegen package.json neu auf statt gegen das gepinnte management-ui/
bun.lock und hinterlässt eine dazu inkonsistente package-lock.json.
Der gelockerte Dirty-Check (--untracked-files=no, letzter Commit)
ignoriert genau dieses Artefakt, weil es zusammen mit anderer fremder
unversionierter Arbeit im Repo liegt — beide Fixes zusammen hätten
also einen Release mit abweichender Dependency-Auflösung klaglos
durchgelassen.

release.sh bricht jetzt hart ab wenn bun fehlt, statt sich auf den
Fallback zu verlassen — Release-Builds (Testing UND Stable) müssen
reproduzierbar aus dem gepinnten Lockfile bauen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

scripts/release.sh

@@ -50,6 +50,15 @@ if [ -z "${GITEA_TOKEN:-}" ]; then
 fi
 export GITEA_TOKEN
 
+# `make ui` fällt bei fehlendem bun auf `npm install` zurück (Convenience
+# für schnelle lokale Builds) — das löst Dependencies gegen package.json
+# neu auf statt gegen das gepinnte management-ui/bun.lock, und hinterlässt
+# eine package-lock.json die nichts mit dem committeten Lockfile zu tun
+# hat. Für einen Release (Testing ODER Stable) ist das nicht akzeptabel —
+# beide Kanäle müssen reproduzierbar aus dem gepinnten Lockfile bauen.
+command -v bun >/dev/null 2>&1 || \
+  abort "bun fehlt — Release-Builds müssen aus management-ui/bun.lock bauen, nicht aus dem npm-Fallback. Installieren: https://bun.sh/install"
+
 # ─── Testing-Version: datumsbasiert YYYY.MM.DD.NN ──────────────────────
 # NN = laufende Nummer für den Tag, ermittelt aus den bereits im Registry
 # vorhandenen Versionen des Meta-Pakets (edgeguard) mit dem heutigen