Update dependency kubernetes/kubernetes to v1.37.1

The project key was a guess. The project exists in SonarQube as
JLab-Helm-Charts; jlab-cluster_helm-charts was reasoned from the instance
serving two owners, and it produced the one error message that covers both a
non-existent project and a token without permission on it:

  ERROR You're not authorized to analyze this project or the project doesn't
        exist on SonarQube and you're not authorized to create it.

Because the server does not distinguish those two cases, the next occurrence of
that message now means the token lacks "Execute Analysis" - which is worth a
comment in the file rather than a second round of guessing.

sonar.projectName goes away entirely. Once the project exists on the server the
display name belongs to the server, and a name sent with every analysis would
overwrite a rename there on every run, silently. The reason is a comment in the
file so the line is not added back as an obvious omission.

The README analyser table was built from SonarQube's language list and promised
more than this instance delivers. Measured in run 375: two quality profiles
loaded, json and yaml; the IaC Kubernetes sensor (3.4 s) and the secrets
detection over all 391 indexed files did the work. Shell and GitHub Actions did
not run, and no configuration here can make them - analysers are server-side
plugins. The consequence is now stated: the five ci/ scripts and the thirty
workflow files, the files carrying the actual logic, are not analysed at all.
Whether the instance gains those plugins is a decision outside this repository.

Run 375 also answered the three questions this path carried, all positively:
node24 is in the runner image, the ~59 MiB scanner download and its signature
arrived in roughly three seconds (so the MTU failure that once killed a 17 MB
download does not repeat), and a repository variable does reach a workflow
called from another repository - which settles the identical question the
publish route carried for OP_CONNECT_HOST. The publish route's upload is still
unproven and stays listed as such.

Fixes #74

README.md

@@ -173,19 +173,21 @@ Why it exists at all: the answer arrived once by accident. Gitea PR #48 correcte
 
 ### SonarQube analysis (after the merge, and not a gate)
 
-`sonar.yml` sends the whole tree through a SonarQube analysis. The workflow itself is the shared block [`sonar-analysis.yml`](https://git.jk-dev.de/workflow-util/pipelines/wiki/sonar-analysis) in `workflow-util/pipelines`, bound to `@v4`; the only thing on this side is `sonar-project.properties` in the repo root, holding the project key `jlab-cluster_helm-charts`. The key carries the owner because the instance serves two (`jlab-cluster` and `suer`), and a project key cannot be changed afterwards without losing the project's history.
+`sonar.yml` sends the whole tree through a SonarQube analysis. The workflow itself is the shared block [`sonar-analysis.yml`](https://git.jk-dev.de/workflow-util/pipelines/wiki/sonar-analysis) in `workflow-util/pipelines`, bound to `@v4`; the only thing on this side is `sonar-project.properties` in the repo root, holding the project key `JLab-Helm-Charts`. **That key is read off the existing project in SonarQube, not derived** — it is the one the maintainer set up, and a guessed key (`jlab-cluster_helm-charts`, reasoned from the instance serving two owners) is what made the first run fail. The file carries **no `sonar.projectName`** on purpose: once the project exists, the display name belongs to the server, and a name sent with every analysis would overwrite a rename there silently.
 
-**What is analysed** — the languages were checked against SonarQube's list rather than assumed, and the fit is better than expected:
+**What is analysed — measured, not taken from a language list.** The first run (run 375) loaded exactly **two quality profiles, `json` and `yaml`**; the sensors that did work were **IaC Kubernetes** (3.4 s) and the **secrets detection** (`TextAndSecretsSensor`) over all 391 indexed files.
 
-| What is in this repository | Analyser |
-|---|---|
-| the 5 shell scripts under `ci/` — the whole CI logic | Shell |
-| ~30 workflow files | GitHub Actions |
-| 238 YAML files and 26 Helm template directories | Kubernetes/Helm, YAML |
-| 26 `values.schema.json` | JSON |
-| the whole tree | Secrets |
+| What is in this repository | Analyser | Runs? |
+|---|---|---|
+| 238 YAML files and 26 Helm template directories | IaC Kubernetes, YAML | yes |
+| 26 `values.schema.json` | JSON | yes |
+| the whole tree (391 files) | Secrets | yes |
+| the 5 shell scripts under `ci/` — the whole CI logic | Shell | **no** |
+| the 30 workflow files | GitHub Actions | **no** |
 
-The last row is the valuable one. **The premise of this repository is that no credential ever lands in it** — every secret is a 1Password `OnePasswordItem` reference — and until now nothing checked that premise.
+**The two missing rows are not a configuration mistake, and nothing in this repository can fix them: analysers come from the *server*, not from the scanner.** The language list the earlier version of this table was built from describes the newest SonarQube release; this instance does not have the Shell and GitHub Actions plugins. The consequence is worth stating plainly rather than leaving it to be rediscovered — **the files carrying the actual logic, the five `ci/` scripts and the thirty workflows, are not analysed at all.** What runs is IaC over the charts plus secret detection over everything. Whether the instance gets upgraded or gains those plugins is a decision for whoever runs it, not something this repository settles; `shellcheck` and review remain the only check on the scripts until then.
+
+The secrets row is the valuable one that *does* run. **The premise of this repository is that no credential ever lands in it** — every secret is a 1Password `OnePasswordItem` reference — and until now nothing checked that premise. What it actually reports is still unknown: run 375 built the report (603 kB) but never uploaded it, because the upload is where the wrong project key failed.
 
 **It is not a gate, and that is a decision.** The SonarQube Community Build analyses the **main branch only**; there is no pull-request analysis to hook into, so the trigger is a push to `main` and **a finding appears after the merge**. At that point there is nothing left to block, which is why the shared block carries no quality-gate step: a red gate behind the merge would only colour `main` red without having prevented anything, and a permanent red is a thing people learn to ignore — taking the credibility of `validate-charts` with it. A gate becomes the right thing under one of two conditions: pull-request analysis is available, or a deployment hangs off the workflow. Until then, read the findings in SonarQube; nothing in this repository turns red because of them.
 
@@ -193,7 +195,7 @@ The last row is the valuable one. **The premise of this repository is that no cr
 
 **Prerequisites**, both on the instance and neither in a file here: the repository **variable `SONAR_HOST_URL`** (a variable and not a secret on purpose — the server address is not a credential, and as a variable it stays readable in the log, which is what makes a wrong one diagnosable) and the **secret `SONAR_TOKEN`**, which reaches the block through `secrets: inherit`. The block guards both and names the setting and its place when one is empty. A *missing* `SONAR_TOKEN` never gets that far: the block declares it `required`, and a missing required secret fails job **creation** on this instance, so the run would show no steps at all — the same quirk as everywhere else here.
 
-**Three things about this path are unmeasured**, and the first run after this change is what answers them: whether `node24` is in the runner image (the scan action is a JavaScript action declaring `runs: using: node24`, so a failure will read as an action problem rather than an image one), whether the scanner download gets through — the action fetches the Sonar Scanner CLI from `binaries.sonarsource.com` at run time, ~59 MiB, and a 17 MB download once failed on this runner for MTU reasons (see "What a GitHub runner had been providing quietly") — and whether a repository **variable** reaches a workflow called from another repository, which is the same open question the publish route has for `OP_CONNECT_HOST`. `workflow_dispatch` is on the hull for exactly this: retrying any of them otherwise costs a dummy commit on `main`.
+**Three things about this path were unmeasured, and run 375 answered all three — positively.** `node24` **is** in the runner image, so the JavaScript scan action runs. The scanner download **gets through**: ~59 MiB of archive plus its signature in roughly three seconds, so the MTU failure that once killed a 17 MB download on this runner (see "What a GitHub runner had been providing quietly") does not repeat at five times the size. And a repository **variable does reach a workflow called from another repository** — the block's guard passed and the scanner started, which it could not have done without `vars.SONAR_HOST_URL` arriving. That last one also settles the identical question the publish route carried for `OP_CONNECT_HOST`: same forge version, same mechanism, a repository variable read inside a workflow called from another repository. What the publish route still has unproven is the upload itself, which has never run. `workflow_dispatch` stays on the hull for the retries: without it every attempt costs a dummy commit on `main`.
 
 ## Dependency updates (Renovate)
 

sonar-project.properties

@@ -2,12 +2,30 @@
 # block in workflow-util/pipelines and is identical for every repository that
 # uses it; everything that is about THIS repository lives here.
 #
-# The key carries the owner. The instance serves two owners (jlab-cluster and
-# suer), so a bare "helm-charts" would be free now and collide the moment the
-# second owner has a repository of the same name - and a key cannot be changed
-# afterwards without losing the project's history.
-sonar.projectKey=jlab-cluster_helm-charts
-sonar.projectName=jlab-cluster/helm-charts
+# The key is the one the project already has on the server, given by the
+# maintainer. It is not derivable and must not be guessed: the project is
+# created in SonarQube first, and the key is then read off it.
+#
+# The first attempt here was a guess, "jlab-cluster_helm-charts", reasoned from
+# the instance serving two owners. It failed with
+#
+#   ERROR You're not authorized to analyze this project or the project doesn't
+#         exist on SonarQube and you're not authorized to create it.
+#
+# which is the message for BOTH a wrong key and a token without "Execute
+# Analysis" on the project - the server does not distinguish them, so a wrong
+# key here looks exactly like a permission problem over there. Once the key is
+# known to be right, that message means the token.
+sonar.projectKey=JLab-Helm-Charts
+
+# NO sonar.projectName, deliberately.
+#
+# The project exists on the server, so the display name belongs to the server:
+# whoever renames it there expects the rename to hold. A name sent with the
+# analysis would overwrite it on every single run, silently, and the person who
+# renamed it would only see it snap back. A value that rewrites someone else's
+# setting without saying so is not a value this repository carries. If the name
+# is wrong, it gets fixed in SonarQube, not here.
 
 # The whole tree, which is also the scanner's default - stated rather than
 # implied, because the absence of exclusions below is a decision and an empty