ci: call the shared SonarQube block, and say what it does not do

Adds the caller side of the analysis: .github/workflows/sonar.yml as a hull of
the same kind as the publish ones, and sonar-project.properties as the
project-specific half. The workflow itself is the shared block in
workflow-util/pipelines, bound to @v4.

No paths filter, unlike the publish hulls: the analysis looks at the whole tree
- the five shell scripts under ci/, every workflow file, the YAML and Helm
templates, the values.schema.json files, and the secret detection over
everything. A filter would leave the previous result standing after a change it
did not cover while still presenting it as current.

workflow_dispatch is on the hull on purpose. Three things about this path are
unmeasured - node24 in the runner image, the ~59 MiB scanner download, and
whether a repository variable reaches a workflow called from another repository
- and any of them may need more than one attempt. Without a dispatch every
attempt would cost a dummy commit on main.

No exclusions, including the Helm templates, which are not valid YAML because
of {{ }}. What the Helm and YAML analysers make of them is only learnable by
letting them run over them once, and an exclusion written on a guess hides
whatever else matches it. If the first run produces noise worth suppressing,
the exclusion belongs in sonar-project.properties with the finding it answers
named next to it.

The project key carries the owner (jlab-cluster_helm-charts) because the
instance serves two, and a key cannot be changed afterwards without losing the
project's history.

The analysis is not a gate. The Community Build analyses the main branch only,
so the trigger is a push to main and a finding appears after the merge - at
which point there is nothing left to block. README and the CI-CD wiki page both
say so, with the two conditions under which a gate would become right, so that
its absence is not read as an oversight.

sonar-project.properties

@@ -0,0 +1,32 @@
+# Project-specific half of the SonarQube analysis. The workflow is the shared
+# 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 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
+# file would not show that.
+sonar.sources=.
+
+# NO EXCLUSIONS, deliberately, for the first round.
+#
+# The interesting case is the Helm templates: because of {{ }} they are not
+# valid YAML, and what the Helm and YAML analysers do with them is something we
+# can only find out by letting them run over them once. Excluding them up front
+# would throw away the only chance to learn it, and it would exclude the 26
+# chart template directories that are the bulk of this repository.
+#
+# The same goes for the secret detection, which is the most valuable analyser
+# here: 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.
+#
+# If the first run produces noise that is genuinely not worth reading, the
+# exclusions belong here, with the finding they answer named in a comment. Not
+# before: an exclusion written on a guess hides whatever else matched it.