chore(chart): appVersion 0.2.4, chart 0.3.4 (elasticsql 0.20.3 train)

[fupelaqu]

Last of the six-repo release train: core → extensions → arrow → jdbc → repl → helm. This chart depends on arrow's docker images, not on the repl bundle, so it is unblocked as soon as arrow is released.

The merge blocker is now cleared

The commit body says do not merge until the images exist — when the branch was authored, all five 0.2.4 tags answered 404. appVersion is the default image tag, so merging early would have shipped a chart whose pods cannot pull.

Re-checked just now, all five are published:

softnetwork/softclient4es-federation:0.2.4          2026-08-04T11:10:51Z    897 MB
softnetwork/softclient4es6-arrow-flight-sql:0.2.4   2026-08-04T11:11:28Z    922 MB
softnetwork/softclient4es7-arrow-flight-sql:0.2.4   2026-08-04T11:11:37Z    930 MB
softnetwork/softclient4es8-arrow-flight-sql:0.2.4   2026-08-04T11:11:28Z    951 MB
softnetwork/softclient4es9-arrow-flight-sql:0.2.4   2026-08-04T11:11:38Z    950 MB

That is the federation image and all four sidecars, which is what the Chart.yaml comment above appVersion requires — a chart that renders a sidecar tag nobody built fails at pull time, not at template time, so no CI gate here would have caught it.

What the chart inherits

via	version	what it brings
elasticsql	0.20.3	local-file COPY INTO without Hadoop (#183), ES client exception status preserved (#184), single-table materialized views (#185), and a DDL statement that can succeed with a warning
extensions	0.2.3	the refresh watcher is optional — a JOIN materialized view is created with a warning on a basic licence instead of rolling back
arrow	0.2.4	statement-kind routing allowlist, so a DDL statement carrying a JOIN reaches the materialized-view extension and not the federation JOIN planner (softclient4es-arrow#130)

Changes

• Chart.yaml: chart 0.3.3 → 0.3.4, appVersion 0.2.3 → 0.2.4, plus the changelog entry the file keeps inline.
• All seven goldens regenerated. The diff is only what appVersion drives: image tags, helm.sh/chart, app.kubernetes.io/version, and the ConfigMap checksums that follow from them — no template change is hiding in there.

Verification (the workflow's own gates, run locally)

• helm lint — clean.
• All seven goldens re-render byte-identical to what is committed, using the same commands as the drift gate (no --set image.tag, since the committed goldens are appVersion renders).
• example-three-region.yaml and example-heterogeneous-ready.yaml remain byte-identical to each other, which is the workflow's deliberate anti-copy check — a regression that copies one example over the other would otherwise pass both the golden diff and the smoke undetected.