docs: name the remote that exists, and a push rule for the wiki

The remote bullet described two remotes, github and JLab-Git, and denied
that origin exists. The checkout has exactly one, origin, pointing at the
Gitea instance, and so does every worktree cut from it; two agents lost
time on the difference. The point the bullet made survives — Gitea is the
leading copy, the mirror is fed from there, and where a second remote does
exist the advice to name it still holds.

The wiki has no PR flow, so parallel edits meet only at push time. During
Gitea #16 and #18 two agents edited the same two pages minutes apart and
the rebase happened to be clean; a force push would have deleted the other
edit with nothing to report it. Fetch and rebase before every push, never
force-push.

The chart pages no longer quote versions, so the sentence that explained
them as snapshots now says they carry no numbers at all. That change is
already in the wiki.

CLAUDE.md

@@ -30,6 +30,8 @@ git clone ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.wiki.git
 
 Flat layout, one Markdown file per page, page name = file name, links are relative page names without the extension (`[CI/CD](CI-CD)`). A new page must also be listed in `_Sidebar.md`, or it is reachable only by search.
 
+**There is no PR flow here, so fetch and rebase before every push and never force-push** — two agents have already edited the same page minutes apart, and a force push deletes the other edit silently, with nothing left to report it.
+
 **What obliges a wiki edit** (step 7 of the workflow above, same round of work, never a follow-up issue):
 
 | Change | Page |
@@ -43,7 +45,7 @@ Flat layout, one Markdown file per page, page name = file name, links are relati
 | a Renovate rule added or changed | `Renovate` |
 | something broke in a way a rule now prevents | `Lessons-Learned` |
 
-**What does not oblige an edit:** a plain app-version bump. Renovate automerges those continuously and never touches the wiki, which is why chart pages quote versions as snapshots and name `Chart.yaml` as the source of truth. An app update that *does* change values or behaviour is not a plain bump, and the table applies.
+**What does not oblige an edit:** a plain app-version bump. Renovate automerges those continuously and never touches the wiki, which is why chart pages carry no version numbers at all and name `Chart.yaml` as the source of truth. An app update that *does* change values or behaviour is not a plain bump, and the table applies.
 
 Wiki commits follow the same rules as repo commits: no `Co-Authored-By`, no "Generated with Claude Code" footer.
 
@@ -52,7 +54,7 @@ Wiki commits follow the same rules as repo commits: no `Co-Authored-By`, no "Gen
 Everything runs on the Gitea instance JLab-Git: issues, pull requests, CI and Renovate. github.com is a push mirror with Actions and Renovate **switched off**, and it lags until the mirror runs. README, "Where this repo lives", holds the measured differences between a Gitea runner and a GitHub one.
 
 - **`tea`, not `gh`.** Work happens in a **Coder workspace, and it has no `op`** — that is the normal case here, not a broken environment, so do not wait for the 1Password CLI or propose installing it. Call `tea` directly; it carries the workspace's stored login and opens PRs and issues under the **bot account**, which is accepted. Say so in the report when something is authored that way. (`op plugin run -- tea`, the older instruction, applies only where `op` actually exists.)
-- **Remotes are named `github` and `JLab-Git`** — there is no `origin`. `JLab-Git/main` is the leading copy; say which remote you mean, because `git push` without one is ambiguous here.
+- **The remote is `origin`, and it points at Gitea** (`ssh://git@git.jk-dev.de:30022/jlab-cluster/helm-charts.git`). The checkout has exactly that one, and so does every worktree cut from it, so a bare `git push` goes to the leading copy; the github.com mirror is fed by Gitea itself and is never pushed to by hand. A clone elsewhere may carry the mirror as a second remote named `github` — wherever more than one exists, say which one you mean.
 - **Branch protection with a signature requirement is active**, and signatures verify on Gitea. A commit that is not signed does not reach `main` — check before opening a PR, do not discover it at merge time.
 - **No merge queue.** Gitea has none, and its place is taken by **auto-merge on green checks**: the PR is armed once and merges itself when the required check passes **and the required review exists** — both are active on `main`, so an armed PR without a review sits there instead of merging. Rule 6 above is unchanged — the user merges, and an agent never merges its own PR or arms auto-merge on it.
 - **A required check per chart is not possible.** Gitea runs a whole matrix as one job under one status context, so the install-test reports once for all charts. What is required on `main` is `validate-charts`, as that single context; per chart is the part that cannot be had. Relevant whenever branch protection is touched.