matrix: inventarisieren, MATRIX-01/02 verifiziert erledigt, MATRIX-04 neu

MATRIX-01 (Mail-Absender-Frage): per Config verifiziert, dass weder Synapse
noch MAS Mail versenden - kein Konfigurationsblock in den deployten Werten.
MATRIX-02: Korrektur einer falschen Annahme - "k3s-Host (10.0.0.2)" und
"matrix" sind dieselbe Maschine, nicht zwei getrennte. Remote-Write nutzt
bereits die private IP. MATRIX-04 neu: Host-Level Pre-Update-Benachrichtigung
(Issue #24). Cross-Referenzen in zone-axion1337.md (ZONE-02 entblockt) und
cfgmon.md (CFGMON-03-Update, neues CFGMON-08 fuer die Gitea-Runner-Standortfrage)
aktualisiert.

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

hosts/cfgmon.md

@@ -147,8 +147,16 @@ umgesetzt ist er nicht.
 **Nächster Schritt:** Beide Ports per Hetzner-Cloud-Firewall auf die Absender
 einschränken. Sauberer wäre, sie gar nicht öffentlich zu binden: k3s liegt mit
 `10.0.0.2` im selben privaten Netz wie CFGMON (`10.0.0.3`), der Push könnte also
-über das private Netz laufen. Für den Matrix-Server auf `49.13.132.245` prüfen, ob
-er in dasselbe Netz aufgenommen werden kann — siehe [matrix](matrix.md).
+über das private Netz laufen.
+
+**Update 2026-07-30**: der k3s/Matrix-Host (`49.13.132.245`, privat `10.0.0.2` — ist
+derselbe Host, siehe [MATRIX-02](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus--erledigt-2026-07-30))
+nutzt für seinen eigenen Remote-Write/Loki-Push bereits die private IP
+(`http://10.0.0.3:9090`/`:3100`, verifiziert in `apps/monitoring/alloy-config.yaml`), nicht
+`188.245.193.243`. Der öffentlich erreichbare, unauthentifizierte Port bleibt trotzdem ein
+CFGMON-seitiges Risiko (jeder im Internet könnte ihn ansprechen, nicht nur der k3s-Host) -
+dieser Teil des Punkts ist also weiterhin offen, nur nicht mehr durch fehlende
+Netz-Erreichbarkeit des Matrix-Hosts blockiert.
 
 ---
 
@@ -171,6 +179,34 @@ sauberer, weil dafür kein Admin-Passwort nötig ist.
 
 ---
 
+## CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen
+
+**Status:** offen
+
+`gitea.rohana.axion1337.de` (dieser Host) hostet mehrere Repos mit `.gitea/workflows/`
+(u. a. `axion1337.chat-gitops`, `ThreadNet-Web`), aber es läuft **kein Runner** — Workflows
+existieren, greifen aber nie. Tracking der eigentlichen Notwendigkeit (drei Baustellen
+hängen daran: Web-/Desktop-Build-CI, Electron-Automatisierung, npm-Publish für
+`threadnet-call`) läuft zentral in
+[gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) — hier nur
+die **Standort-Frage**, die noch nicht entschieden ist:
+
+- **Auf CFGMON** (neben Gitea selbst): kürzeste Wege zu Gitea, aber dieser Host hat laut
+  [CFGMON-02](#cfgmon-02--traefik-gitea-und-cadvisor-sind-nicht-versioniert) ohnehin schon
+  unversionierte Infrastruktur - ein weiterer nicht-deklarativer Baustein wäre ungünstig,
+  außer der Runner wird von Anfang an sauber (IaC) aufgesetzt.
+- **Auf dem k3s/Matrix-Cluster** (siehe [matrix](matrix.md)): passt zum GitOps-Modell dort
+  (alles deklarativ), Runner-Pod bräuchte aber Netzzugriff zu Gitea auf CFGMON - existiert
+  bereits privat (`10.0.0.2` ↔ `10.0.0.3`).
+- **Secret-Handling für CI-Tokens** (z. B. der npm-Publish-Token für `threadnet-call`):
+  unabhängig vom Standort über Gitea Actions' eigene Secrets-Funktion (Repo-/Org-Settings),
+  nicht SOPS - siehe Begründung in gitops#33.
+
+**Nächster Schritt:** Standort entscheiden, dann Runner registrieren, dann #33 und die
+verlinkten Issues (ThreadNet-Web#2, gitops#44) abarbeiten.
+
+---
+
 ## Erledigt
 
 ### CFGMON-05 — Monitoring-Stack unter IaC bringen · erledigt 2026-07-30