webpage: the four git-syncs read Gitea in-cluster; sidecars retry forever (--max-failures=-1); gate 6 keeps the --repo values identical

On 2026-10-19 09:24 the public path to Gitea failed once and the sidecar exited (max-failures defaults to 0).
Anonymous in-cluster fetch proven first (main and installer-v1.34.0 resolve to the public hashes).

documentation/architecture/01-topology-and-trust.md

@@ -271,6 +271,13 @@ app. Controller down → the gated app answers an error, never the app. Measured
   tunnel. Since controller v0.286.0 it sits ALONE on the `felhom-tunnel` network at the fixed address `172.16.253.2`
   (traefik at `.3`), so traefik can believe forwarded headers from it and from nothing else (§5). Geo-restriction WAF
   is **hub-enforced** (the hub holds the CF API token; the controller only reports geo desired-state).
+- **[DESIGN] The website's content comes from Gitea IN-CLUSTER** (2026-10-19). The `felhom-webpage` pod pulls
+  `website/` (from `main`) and `scripts/` (from the `installer-v…` tag, R-110) with four git-syncs that read
+  `http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom.eu.git` — plain HTTP, safe only because it never
+  leaves the cluster (the hub's own Gitea client does the same). No internet hop: the pod can start, and keep its copy
+  fresh, during an internet outage. The two sidecars run with `--max-failures=-1`, so an unreachable Gitea is retried,
+  not a restart. **This ties the website to the DooPlex cluster:** moved elsewhere, it must read the public HTTPS
+  address again. `scripts/hostinstall_gates.py` gate 6 keeps the four `--repo` values identical.
 
 ---