chore(chart): appVersion 0.3.0, chart 0.3.6 + retire the licence public-key value

[fupelaqu]

Fifth repo in the 0.3.0 train. The chart depends on arrow, not jdbc, so it can land while the jdbc release finishes.

surface	before	after
Chart.yaml version	0.3.5	0.3.6
Chart.yaml appVersion	0.2.5	0.3.0
workflow IMAGE_TAG	0.2.5	0.3.0
7 golden renders	—	regenerated

IMAGE_TAG is the surface whose own comment records it going stale on the 0.2.2 train and again on 0.2.4. It moves here in the same commit as appVersion.

All five images were verified published on DockerHub at 0.3.0 before appVersion moved — the federation image and all four softclient4es{6,7,8,9}-arrow-flight-sql sidecars — because a Chart.yaml pointing at a tag that does not exist breaks every install.

⚠️ Breaking — and why this is more than a version bump

extensions 0.3.0 embeds the licence trust root, so SOFTCLIENT4ES_LICENSE_PUBLIC_KEY is no longer consulted.

This chart set that variable, from license.publicKeySecretName — and the docs recommended it as the remedy for InvalidLicense: Unknown key ID. Left alone, the chart would have gone on advertising a knob that silently does nothing, in a troubleshooting table, as the fix.

The value now aborts the render rather than being deleted:

execution error at (softclient4es-federation/templates/deployment.yaml:13:4):
license.publicKeySecretName is no longer supported: as of appVersion 0.3.0 the
licence trust root is embedded in the image, and SOFTCLIENT4ES_LICENSE_PUBLIC_KEY
is ignored. Remove license.publicKeySecretName (and license.publicKeyKey). A
licence issued by the SoftClient4ES licence server verifies with no extra
configuration.

Deleting the key would have been just as silent as leaving it — Helm ignores unknown --set keys. A value that used to decide how a licence is verified has to fail loudly.

Who is actually affected: nobody holding a licence issued by the SoftClient4ES licence server. That verifies against the embedded root with no configuration at all, air-gapped included — the value was always redundant for them. Only a non-production-signed JWT breaks, and those operators now find out at helm upgrade instead of via CrashLoopBackOff.

CI

SC4ES_TEST_PUBLIC_KEY is gone — 6 references. Two of them were --set license.publicKeySecretName=sc4es-license, which the new guard would have aborted: the Pro-tier install and upgrade jobs would have failed outright had the workflow not moved together with the chart.

The Pro gate now needs one secret instead of two. ⚠️ SC4ES_PRO_TEST_JWT must now hold a licence-server-issued JWT — a self-signed test JWT can no longer be made to verify by supplying its public key. If the current secret is self-signed, the Pro-tier jobs will skip/fail until it is re-minted.

A new static gate asserts the guard fires, that the abort still names the value (an abort whose text drifted generic leaves an operator with nothing to act on), and that no committed values file renders the variable.

Docs updated

README.md (values table, offline-verification callout, CI secrets, troubleshooting row), docs/operator-guide.md (config table, offline-verification callout), examples/three-region/README.md, and the values.yaml comments.

Verification

• helm lint clean; all 7 goldens match a fresh render.
• Golden diff is label / image-tag / ConfigMap-checksum only — no structural change (the env block rendered nothing at the "" default, so its removal is invisible in the renders).
• kind: Secret count still 0 (16.3 contract).
• three-region and heterogeneous-ready still byte-identical (16.4 A2b).
• kubeconform -strict: 3/3 valid.
• The guard aborts with the correct message; the normal Pro path (license.secretName alone) still renders and still injects SOFTCLIENT4ES_LICENSE_KEY.
• Workflow YAML parses; static-checks goes 8 → 9 steps.

Refs #57.