Fix broken template references in minio and s3proxy routes

[ArnobKumarSaha]

Follow-up to #1333, which noted these while verifying that change. Both charts failed helm template on master whenever gateway.enabled=true.

minio

• $fullName was assigned from service-backend.fullname and the labels from service-backend.labels — neither is defined in the minio chart (it has no parent chart; nothing depends on it). Both now use the minio.* helpers.
• The backendRef resolved minio.fullname with . while inside range .paths, so the scope was a path map. It now uses $fullName, matching the service name in charts/minio/templates/service.yaml:4.

s3proxy

• Same range-scope bug on the backendRef service name — now include "s3proxy.fullname" $.
• BackendTLSPolicy.validation.hostname was index .Values.gateway.hosts 0, which is a {host, paths} map, not a string. s3proxy is a subchart of ace (charts/ace/Chart.yaml:39), and the backend certificate is issued for <ace.fullname>-s3proxy on an IP host and for the platform host on a domain host (charts/ace/templates/ingress/certificate.yaml:24-33). The hostname now follows that split, the same way charts/ace/templates/gateway/route-nats.yaml:67-71 does — so validation matches a SAN that is actually on the cert.

Verification

helm template on minio standalone, and on s3proxy with an ace.fullname stub (its parent's helper), for both hostType: ip and hostType: domain: routes render, backendRefs resolve to the real service names, and the TLS hostname is ace-s3proxy / the platform host respectively. helm lint passes on both.

Not changed

s3proxy's caCertificateRefs hardcodes <ace.fullname>-gw-cert, while route-nats.yaml:56-66 switches to -acme-ca-cert when the issuer is letsencrypt. That looks like the same divergence, but it is out of scope here — happy to follow up.

[ArnobKumarSaha]

Pushed bd26b36, which closes the open question from the PR description — the caCertificateRefs divergence with route-nats.yaml is now fixed here rather than in a follow-up.

Why nats' approach is the correct one: lib-selfhost/lib/installer.go:2664-2672 sets s3proxy's serving cert to tplNATSTLSSecret(in), which is <release>-gw-cert whenever the gateway is enabled (installer.go:3712-3719) — no hostType branch. nats gets the same secret, confirmed on a live install (s3proxy.s3proxy.tls.secret.name and nats.nats.tls.secret.name are both ace-gw-cert). Same cert and issuer means the same CA, and a letsencrypt-issued secret has no usable ca.crt, which is what charts/ace/templates/gateway/acme-ca.yaml exists for.

That also confirms the hostname change above: s3proxy serves ace-gw-cert, whose SANs are <tenant>-s3proxy* on an IP host and the platform host on a domain host (charts/service-gateway/templates/gateway-tls/certificate.yaml:19-40).

Worth noting for review: this block is currently unreachable. out.S3proxy.Gateway is written in exactly one place (installer.go:2648-2652) and never sets Hosts, in either mode, so {{- if (index .Values "gateway" "hosts") }} at charts/s3proxy/templates/httproute.yaml:3 is always false and only the TCPRoute renders. That is why the broken index .Values.gateway.hosts 0 never surfaced. These fixes matter when gateway.hosts starts being set.

Verified by rendering with global.infra.tls.issuer set to ca / letsencrypt / letsencrypt-staging / external: the acme CA is selected for the two letsencrypt issuers and -gw-cert otherwise, matching route-nats.yaml:56-66.