feat(operator): give the SimplyblockDriver a TLS spec surface

[boddumanohar]

Why

#513 moved the CSI driver's deployment out of the Helm chart and into the SimplyblockDriver kind the operator reconciles — but the new kind had no field for TLS, so adoption refused any deployment carrying it outright:

// TODO(simplyblockdriver): give TLS and csi-link a spec surface. The chart
// could express both and this kind cannot, so adoption refuses a deployment
// carrying either rather than reconciling it away

That's not a hypothetical gap. In simplyBlockDeployGCP's e2e workflow, I had to explicitly drop --set tls.enabled=true --set tls.mutual_enabled=true from the Helm install just to get the new driver-adoption path to work at all — any cluster running with TLS on had no way to move its CSI driver onto SimplyblockDriver.

What this does

spec.tls (enableTLS, enableMutualTLS, provider) reproduces the chart's tls.enabled / tls.mutual_enabled / tls.provider as one nested struct — the same pattern spec.sidecarImages already established for a chart value that had to survive the move to a CRD.

The env, the volume, and the mount it produces are byte-for-byte what the chart rendered (FDB_TLS_* included, even though neither plugin reads it), because workloads.go's own rule is that a Created deployment's objects have to match an already-running one, or adoption becomes a rolling restart instead of a no-op.

The client-certificate Secret each plugin mounts is derived, not a spec field: <object name>-csi-{controller,node}-client-tls, the same names.go pattern every other object already follows, and the literal names this chart's controlplane_certificates.yaml already writes for cert-manager. A field naming them again would just be a second place for the two to disagree.

Adoption's TLS refusal is now a comparison, not a blanket no — the same shape as the existing driverName check: the running node plugin's SB_TLS_CONNECT is compared against what spec.tls would produce, and only a disagreement refuses. Unlike driverName, this one is repairable: edit spec.tls to describe what's actually running, and the next reconcile adopts.

Verification

• go build ./..., go vet ./..., go test ./... clean (one unrelated pre-existing envtest failure in internal/controller from a missing local etcd binary — confirmed pre-existing by stashing this change and re-running).
• check-crds.py --paths and check-reconcilers.py --paths: 0 errors.
• House-style quality gate: clean (one pre-existing, unrelated xfs/XFS note in a comment I didn't touch — it's intentionally lowercase there, quoting a literal enum value).
• make -C operator manifests generate, make helm-sync, make -C operator build-installer: regenerated CRD, deepcopy, chart copy, dist/install.yaml. No side effect on config/manager/kustomization.yaml.
• 12 new unit tests (tls.go's builders, plus 5 new adoption-mismatch cases), all passing.
• Design doc (design-simplyblockdriver.md) and test plan (test-plan-simplyblockdriver.md) updated in the same change, per this repo's API-design checklist.

Side note

The api-design checker's foreign-value allow-list (check-crds.py) gained cert-manager alongside its existing ext4/tcp entries — a product's own name is the documented exception to this group's PascalCase enum rule, and cert-manager is lowercase-hyphenated the same way tls.provider already spells it everywhere else in this operator (internal/utils/tls.go's existing TLSProviderCertManager constant).

🤖 Generated with Claude Code