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).

scripts/CHANGELOG.md

@@ -1,3 +1,13 @@
+## 2026-10-19 — the website's git-syncs read Gitea in-cluster and retry forever (`manifests/webpage.yaml`, gate 6)
+
+On 2026-10-19 09:24 the public path to Gitea failed once; git-sync v4.4.0 (`--max-failures` defaults to 0) exited
+(`too many failures, aborting … failCount:1`) and the sidecar restarted. Visitors saw nothing, but a pod starting
+during an outage could not seed its pages at all. All four git-sync containers now read
+`http://gitea.gitea-system.svc.cluster.local:3000/admin/felhom.eu.git` (anonymous fetch proven first: `main` and
+`installer-v1.34.0` resolve in-cluster to the same hashes as the public address); the two sidecars carry
+`--max-failures=-1`. `hostinstall_gates.py` gate 6 now also fails when the four `--repo` values differ (red-proved:
+one changed → FAIL, restored → OK). Refs unchanged; `nginx-config-rev` unchanged.
+
 ## 2026-10-18 — CI workflow: the failure mail links the public run page, by run id (R-1135)
 
 `.gitea/workflows/gates.yml`, the alarm step: the mail's run link is now `https://gitea.dooplex.hu/<repo>/actions/runs/<run id>`.