Drop sudo from the deploy workflow - NoNewPrivileges blocks it outright

sudo needs setuid escalation, which the runner's own unit disables
entirely via NoNewPrivileges=yes (unconditionally, independent of any
sudoers config - the earlier sudoers.d/deploy-runner grant was never
going to work). Caddy reload already works via the runner's existing
docker group membership; the service restart now goes through plain
systemctl (talks to PID1 over D-Bus, no escalation needed), authorized
by a new polkit rule scoped to deploy-runner + app@*.service.

.gitea/workflows/deploy.yml

@@ -74,9 +74,17 @@ jobs:
           LEPTOS_SITE_ADDR=0.0.0.0:3010
           EOF
 
+      # No sudo: the runner's own unit sets NoNewPrivileges=yes, which
+      # blocks setuid escalation outright (sudo can't work at all under
+      # it, regardless of sudoers config) - systemctl talks to PID1 over
+      # D-Bus instead, authorized by a polkit rule scoped to deploy-runner
+      # + this unit pattern (see /etc/polkit-1/rules.d/10-deploy-runner.rules
+      # on the host).
       - name: Restart service
-        run: sudo systemctl restart app@uhhm-portal.service
+        run: systemctl restart app@uhhm-portal.service
 
+      # No sudo here either - the runner is already in the `docker` group,
+      # so it can talk to the Docker socket directly.
       - name: Update Caddy routing
         run: |
           cat > /etc/caddy/services.d/uhhm-portal.caddy <<'EOF'
@@ -85,4 +93,4 @@ jobs:
           	log { output file /var/log/caddy/www.log }
           }
           EOF
-          sudo docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile
+          docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile