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

.claude/rules/manifests.md

@@ -29,5 +29,7 @@ ArgoCD's source of truth is the **manifest in git**:
 `main`, and `/scripts/` from the tag `installer-v<SCRIPT_VERSION>`. Changing either `--ref` changes
 what real machines download — the init container **and** the sidecar both carry it, and both must
 move together. `hostinstall_gates.py` gate 6 fails if the manifest stops naming an `installer-v…`
-tag or if the website stops tracking `main`. The full publish/rollback procedure is the R-110 fence
+tag or if the website stops tracking `main`. All four git-sync containers (two sidecars, two init containers) read
+Gitea **in-cluster** (`http://gitea.gitea-system.svc.cluster.local:3000/…`, since 2026-10-19) and must name the same
+repo — gate 6 fails if they differ; the sidecars carry `--max-failures=-1` (retry, never exit). The full publish/rollback procedure is the R-110 fence
 in the repo core `CLAUDE.md`.