feat: support kubeconfig on `helm template` (to enable `lookup` template function)

[onionlzl]

Background

helm template currently runs client-only in helm-java — template.go:50 passes ClientOnly: true to the internal install call. This means the lookup template function (which queries the live cluster during rendering) doesn't work.

Helm CLI's helm template supports --kube-config / --kube-context / etc. precisely to enable lookup and other cluster-aware rendering paths.

Acceptance criteria

• TemplateCommand.withKubeConfig(Path) and withKubeConfigContents(String) work
• When either is set, the template render can resolve lookup calls against the live cluster
• When neither is set, current client-only behavior is preserved
• Integration test (nested in HelmKubernetesTest.Template) renders a chart using lookup and asserts the rendered manifest contains data from a Kubernetes object created in the test

Proposed Java API

helm.template()
    .withKubeConfig(kubeConfigPath)
    .call();
// chart can now use {{ (lookup "v1" "ConfigMap" "default" "my-cm").data.key }}

Implementation guide

Reference impl: existing TemplateCommand + template.go. The change is small — plumb kubeConfig fields through, and flip ClientOnly based on whether kubeConfig was supplied.

Go (native/internal/helm/template.go)

• Add KubeConfig string and KubeConfigContents string to TemplateOptions.
• In Template(...):

  clientOnly := options.KubeConfig == "" && options.KubeConfigContents == ""
  rel, _, err := install(&InstallOptions{
      DryRun:             true,
      ClientOnly:         clientOnly,
      KubeConfig:         options.KubeConfig,
      KubeConfigContents: options.KubeConfigContents,
      // … existing fields …
  })

CGO bridge (native/main.go)

• Add char* kubeConfig; and char* kubeConfigContents; to struct TemplateOptions. Field order must match JNA struct.
• Pass through.

JNA + Java

• Add public String kubeConfig; public String kubeConfigContents; to lib/api/.../TemplateOptions.java. Update @Structure.FieldOrder and constructor.
• Add withKubeConfig(Path) and withKubeConfigContents(String) to TemplateCommand (copy the methods from InstallCommand).

Tests

• Add a nested Template class to HelmKubernetesTest (shares the KinD container).
• Scenario: pre-create a ConfigMap in the test namespace; render a chart that has {{ (lookup "v1" "ConfigMap" "<ns>" "<name>").data.key }}; assert the rendered output contains the lookup'd value.
• Also keep at least one test in the client-only HelmTemplateTest confirming the no-kubeConfig path still works.

Contributor checklist

• Java 8 syntax only
• Apache 2.0 header
• @author Javadoc tag
• DCO sign-off
• make build-native && ./mvnw test -pl helm-java -Dtest=HelmTemplateTest,HelmKubernetesTest green

References

• Helm CLI: https://helm.sh/docs/helm/helm_template/
• The lookup function: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function
• Project workflow: AGENTS.md → Adding a new Helm command
• Existing kubeConfig plumbing pattern: InstallCommand.java