Deploy this instance from CI

Kasse's runner can now ship a portal release here, the way the ergo
sites already do: PORTAL_RELEASE is the pin, and bumping it is the
rollout. No more ssh and a script run by hand across all three
instances at once.

The runner is not root. It may run one script, which checks the
instance against a fixed list and the tag against a release-tag shape
before it touches anything, and then health-checks the site without a
forwarded header - so a check cannot pass while the site is broken for
everything that is not Caddy, which is how v0.5.1 got out.

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

.gitea/workflows/deploy.yml

@@ -0,0 +1,35 @@
+name: Deploy instance
+
+# This content repo owns its portal instance: which portal version runs
+# on kasse. uhhm/portal only publishes versioned release artifacts;
+# PORTAL_RELEASE below pins the one this site runs, so every rollout is
+# a commit - auditable, and revertable by reverting it.
+#
+# Content-only changes never come through here: lint-and-reload
+# hot-swaps those into the running instance over NATS.
+#
+# Runs on the host runner, because a deploy has to touch this host's
+# filesystem and its units. It is allowed exactly one root action:
+# /usr/local/bin/deploy-portal-instance, which checks the instance
+# against a fixed list and the tag against a release-tag shape before
+# it touches anything, and health-checks the site afterwards without a
+# forwarded header - a check that sends the header Caddy would send
+# cannot tell you the site is broken for everything that is not Caddy.
+
+on:
+  workflow_dispatch:
+  push:
+    branches: [main]
+    paths:
+      - .gitea/workflows/deploy.yml
+
+env:
+  PORTAL_RELEASE: v0.5.2
+  INSTANCE: tomtervel-portal
+
+jobs:
+  deploy:
+    runs-on: fish
+    steps:
+      - name: Ship the pinned release and restart
+        run: sudo /usr/local/bin/deploy-portal-instance "$INSTANCE" "$PORTAL_RELEASE"