charts/redpanda: support schema_registry_client SASL credentials via secretRef

[AldoFusterTurpin]

Summary

The V2 Helm chart had no way to configure SASL credentials for the schema registry's internal Kafka client (schema_registry_client) without storing plaintext passwords in the ConfigMap. This is a regression compared to the V1 operator, which already supports this via operator/pkg/resources/configuration.go.

This PR adds a saslSecretRef field to config.schema_registry_client that references a Kubernetes Secret containing the SASL username and password. Credentials are injected at pod start using the existing redpanda.yaml.fixups mechanism (the same approach already used for tiered storage credentials) so they never appear in plaintext in the ConfigMap or Helm release history.

How it works

1. User sets config.schema_registry_client.saslSecretRef.name=<secret-name> where the Secret has keys username and password
2. Helm writes a redpanda.yaml.fixups entry into the ConfigMap instructing the configurator init container to patch schema_registry_client.scram_username, schema_registry_client.scram_password, and schema_registry_client.sasl_mechanism
3. The init container sources the values from env vars backed by secretKeyRef, applies them to redpanda.yaml, and Redpanda starts with credentials in place

The field names written to redpanda.yaml (scram_username, scram_password, sasl_mechanism) are documented Redpanda broker properties:
https://docs.redpanda.com/current/reference/properties/broker-properties/#schema-registry-client

Test plan

• TestSASLClientFixups: unit test verifying fixup fields and env var names/keys
• TestTemplate/sasl-schema-registry-client-secret-ref: integration test verifying env vars appear in the StatefulSet configurator init container when the feature is used
• TestTemplate/sasl-disabled-secret-ref-ignored: verifies nothing is injected when auth.sasl.enabled is false
• TestTemplate/11-update-sasl-users-values.yaml: existing test, confirmed still passing

Files auto-generated

For reference (even for myself), this is what I did to autogenerate files:

1. Create the build output directory (not created automatically)
   mkdir -p .build

2. Build the gen and gotohelm tools
   PATH="$(pwd)/.build:$PATH" task charts:generate:redpanda

That commands does in order:

1. go:build:gen: builds the gen binary into .build/
2. genpartial:redpanda: generates values_partial.gen.go (partial structs for optional overrides)
3. genschema:redpanda: generates chart/values.schema.json from Go struct tags
4. go:build:gotohelm: builds the gotohelm transpiler binary into .build/
5. gotohelm:redpanda: transpiles the Go source files into chart/templates/*.go.tpl

The PATH prefix is needed because the task builds its own tools into .build/ and they need to be on the path to run.

[CLAassistant]

All committers have signed the CLA.

[AldoFusterTurpin]

@RafalKorepta Could you please take a look when you have some time ? 🙏 I created the PR because I need it for our cluster, but I believe this could be useful for other people as well.

Thank you a lot.