chore(truenas-csi): update the driver to v1.3.0

[jdwillmsen]

Splits the last low-risk entry out of the parked non-major batch (#417) so that
only the two judgement calls remain in it.

What #417 actually still holds

gh pr diff 417 is misleading: it diffs against a stale merge base, so it still
renders eight files' worth of changes. Merging #417 into today's main
(git merge-tree --write-tree origin/main pr417) would add exactly three
things — #436 already landed everything else:

Entry	Status
adminer digest f742dcf	already on main
curlimages/curl 8.22.0 + its allowlist exemption retired	already on main
prometheus/client_model v0.6.3 (+ protobuf v1.36.12)	already on main
golang stage digest 648f440	already on main
kube-prometheus-stack 88.6.5	already on main
prometheus-blackbox-exporter 11.18.0	already on main
grafana 13.2.1	already on main
truenas-csi v1.3.0	this PR
argo-cd 10.8.0	stays in #417 — new controller livenessProbe
nginx-gateway-fabric 2.7.0	stays in #417 — Gateway API v1 TCPRoute/UDPRoute CRD gap

Once this merges, #417 is only the two tenants/platform/tenant.yaml chart
revisions, which is a code-owner-gated file and a real decision either way.

Why v1.3.0 is safe to take on its own

A tag-only bump is not automatically safe for this driver — v1.2.0's own
release notes said "bumping the image tag alone does not deliver the iSCSI
connector, iscsiadm, or topology fixes" and required re-applying the deploy
manifest. v1.3.0 is the opposite case, and the checks below are what establish
that rather than the semver range:

• Upstream says tag-only is enough. v1.3.0 notes: "Existing installs upgrade
  by pulling the new image; nothing needs reconfiguration, and the metrics
  endpoint stays off until you ask for it."
• No CRDs and no schema change. deploy/truenas-csi-driver.yaml at v1.3.0
  contains only CSIDriver, ClusterRole(Binding), ConfigMap, DaemonSet,
  Deployment, Namespace, Secret and ServiceAccount — the same kinds as v1.2.0.
  The CSIDriver spec is untouched.
• The upstream manifest delta is 79 lines and entirely additive/opt-in: a
  TRUENAS_METRICS_ADDR / nodeMetricsAddr env pair sourced from ConfigMap keys
  with optional: true, plus --http-endpoint args on the sidecars. This chart
  sets neither key, so metrics stay off — which is upstream's default too.
• Sidecar pairings do not move. The v1.2.0 and v1.3.0 manifests pin
  byte-identical sidecar versions (provisioner v6.1.1, attacher v4.11.0,
  snapshotter v8.5.0, resizer v2.1.0, livenessprobe v2.18.0,
  node-driver-registrar v2.16.0), so the sidecars: block stays correct.
• The fix in it is one this cluster wants: block-volume expansion no longer
  fails on partitioned devices, which is the KubeVirt/raw-block path.

appVersion moves with the image because values.yaml ties its
"defaults track upstream at the Chart.yaml appVersion" claim to it, and the
PoC runbook line that names the tracked upstream version moves with it for the
same reason. The ADR-0029 line reading "four releases through v1.2.0" and the
pkg/driver/iscsi.go, v1.2.0 source citation in the runbook are deliberately
left alone — both are point-in-time records, and rewriting the citation would
be claiming a source read that did not happen.

Digest verified against the live registry

Renovate's digest is correct — confirmed independently rather than trusted:

$ curl -sSI -H "Authorization: Bearer $TOK" \
    -H 'Accept: application/vnd.oci.image.index.v1+json' \
    https://ghcr.io/v2/truenas/truenas-csi/manifests/v1.3.0
HTTP/2 200
content-type: application/vnd.oci.image.index.v1+json
docker-content-digest: sha256:51dba9c815c9508befeaafde4cc5d99b031b51e5c162e37a1b5675f86e4847ba

That is the multi-arch OCI index digest, which is what values.yaml documents
it must be, not a per-arch child manifest.

Validation evidence

$ python3 tools/check-image-pins.py
image-pin inventory: 21 digest-pinned, 25 allowlisted, 0 unexplained, 0 malformed
  [helm-charts/truenas-csi/values.yaml:20] image: ghcr.io/truenas/truenas-csi:v1.3.0@sha256:51dba9c8...
0 issues — every image reference is digest-pinned or documented.

$ python3 -m unittest discover -s tools/tests -t tools/tests
Ran 245 tests in 5.368s
OK

$ python3 tools/check-remote-chart-image-pins.py
remote-chart image-pin inventory: 24/24 charts checked, 4 allowlisted, 0 unexplained, 0 unreadable

$ python3 tools/check-orphaned-manifests.py
orphaned-manifests: every YAML is watched by ArgoCD or lives in a known non-manifest tree

$ helm lint helm-charts/truenas-csi
1 chart(s) linted, 0 chart(s) failed

$ helm template truenas-csi helm-charts/truenas-csi | kubeconform -summary ...
Summary: 10 resources found in 1 file - Valid: 10, Invalid: 0, Errors: 0, Skipped: 0

The render confirms the one image.tag key pins both halves of the driver —
controller and node both resolve v1.3.0@sha256:51dba9c8..., no version skew.

The repo's kubeconform gate only walks tenants/, excluding values.yaml and
tenant.yaml, so no changed path here is in its scope; the rendered chart was
validated instead.

Not gated

helm-charts/truenas-csi/ and docs/ match no .github/CODEOWNERS pattern
(the gated set is /.github/, /tools/, /renovate.json, /bootstrap/,
/tenants/platform/, /helm-charts/tenant-envelope/, /tenants/*/tenant.yaml,
/cli/), so this needs only the Baseline approval.

Follow-up, deliberately not here

The sidecars: comment claims the pins are "upstream's own pairings for this
driver release", but the values run newer sidecars than upstream pins
(provisioner v6.3.0 vs v6.1.1, attacher v4.12.0 vs v4.11.0, resizer v2.2.1 vs
v2.1.0, livenessprobe v2.19.0 vs v2.18.0, registrar v2.17.0 vs v2.16.0). That
divergence predates this change and is unaffected by it — either the pins or the
comment is wrong, and deciding which is not a dependency bump's call.

🤖 Generated with Claude Code

[jdwlabs-agent-bot]

Reviewed independently of the change's author.

Verified against the live registry: ghcr.io/truenas/truenas-csi:v1.3.0 resolves to sha256:51dba9c8…, exactly the digest pinned here. Upstream's v1.2.0 → v1.3.0 manifest delta is additive metrics plumbing keyed off ConfigMap entries this chart does not set — no CRD, CSIDriver spec or RBAC changes — and the sidecar pairings are unchanged, so the sidecars: block stays correct. The appVersion bump is required rather than cosmetic, because values.yaml ties its "defaults track upstream at the appVersion" claim to it.

Worth stating explicitly: a tag-only bump is not automatically safe for this driver. v1.2.0's notes required re-applying the deploy manifest to actually deliver its fixes; v1.3.0's do not. That distinction, not semver, is what makes this one safe.

19/19 checks green.