feat(runner): zstd installieren, damit der Actions-Cache nicht einkernig gzippt wird (#12)

install/runner-install.sh

@@ -84,13 +84,31 @@ run_user() { runuser -u "$APP_USER" -- env -C "$RUNNER_DIR" HOME="$APP_HOME" "$@
 # (Release-Tarball, buf, oder Docker — der Runner hat Docker) statt sie hier
 # zu heben.
 #
+# zstd: kein Werkzeug fuer Jobs, sondern fuer den Nachlauf. `actions/cache`
+# — und damit auch `actions/setup-go`, das darauf aufsetzt — packt seinen
+# Cache mit `zstdmt`, wenn zstd vorhanden ist, und faellt sonst auf
+# einkerniges gzip zurueck. Der Unterschied ist am Archivnamen zu sehen:
+# `cache.tzst` gegen `cache.tgz`.
+#
+# Gemessen am 02./03.09.2026 in l.kirchner/patchmgr, CI-Lauf 1957: Der Cache
+# aus GOMODCACHE und GOCACHE ist dort 2 bis 5 GB gross. Auf runner-gpu (hat
+# zstd) heisst er `cache.tzst`; auf runner-01/02/03 `cache.tgz`, und
+# `go test -race (stable)` verbrachte damit **605 Sekunden** im Nachlauf bei
+# 41 Sekunden Arbeit. Ueber alle acht Jobs waren es 2312 von 3146 Sekunden.
+#
+# Das ersetzt nicht die Frage, ob dieser Cache ueberhaupt gebraucht wird — im
+# Host-Mode mit dauerhaftem Zuhause ueberleben beide Verzeichnisse ohnehin
+# zwischen den Jobs, und patchmgr schaltet ihn deshalb ab. Aber solange
+# irgendein Repo der Instanz ihn nutzt, soll er nicht einkernig komprimiert
+# werden. Belege: .specs/reports/ci-laufzeit-und-cache-2026-09-02.md dort.
+#
 # Bewusst NICHT installiert: sudo. Ein Workflow soll auf diesem Runner nichts
 # nachinstallieren koennen — was gebraucht wird, steht hier.
 #
 # Go selbst gehoert nicht hierher: Projekte holen es ueber actions/setup-go,
 # weil CI-Matrizen mehrere Fassungen fahren.
 setup_base_apt git rsync ca-certificates curl \
-  make gcc protobuf-compiler libprotobuf-dev
+  make gcc protobuf-compiler libprotobuf-dev zstd
 
 NODE_HAVE="$(command -v node >/dev/null 2>&1 && node -v | sed -E 's/^v([0-9]+).*/\1/' || echo 0)"
 if [[ "$NODE_HAVE" != "$NODE_MAJOR" ]]; then