fix(k8s): make the Helm chart work under any release name

[aicam]

What changes were proposed in this PR?

The chart derives in-cluster hostnames from .Release.Name, but the lakefs and
lakekeeper sub-charts have to address Postgres and MinIO from their own values
blocks — and Helm does not template values files, so those references are hardcoded to
texera-postgresql / texera-minio:

# bin/k8s/values.yaml
lakefs:
  secrets:
    databaseConnectionString: postgres://postgres:root_password@texera-postgresql:5432/...
  lakefsConfig: |
    blockstore:
      s3:
        endpoint: http://texera-minio:9000
lakekeeper:
  externalDatabase:
    host_read: texera-postgresql
    host_write: texera-postgresql

Those names only exist when the Helm release happens to be named texera. Install under
any other release name and they dangle — LakeFS cannot reach the database or the object
store, and Lakekeeper cannot reach the database, while every other service (which goes
through {{ .Release.Name }}-postgresql in the templates) works fine. The failure is
confusing because the chart installs cleanly and only the storage tier misbehaves.

Rendering helm template myrel bin/k8s on main today:

Reference	Points at	Service actually created
Secret/myrel-lakefs → database_connection_string	texera-postgresql	myrel-postgresql
ConfigMap/myrel-lakefs → blockstore.endpoint	texera-minio:9000	myrel-minio
Secret/myrel-lakekeeper-config-envs → LAKEKEEPER__PG_HOST_R / _W	texera-postgresql	myrel-postgresql

The fix. Since the referencing side cannot be templated, make the referenced side a
constant: pin the two sub-charts with fullnameOverride, and resolve the same names in
chart templates through two new helpers so both sides always agree.

postgresql:
  fullnameOverride: texera-postgresql
minio:
  fullnameOverride: texera-minio

{{- define "texera.postgresql.fullname" -}}
{{- .Values.postgresql.fullnameOverride | default (printf "%s-postgresql" .Release.Name) -}}
{{- end -}}

The helpers keep the previous <release>-<chart> form as a fallback, so clearing the
override restores the old naming rather than breaking the chart. The 12 template
references to {{ .Release.Name }}-postgresql (JDBC URLs + the password secretKeyRef),
the two MinIO references in _helpers.tpl, the LiteLLM DATABASE_URL, and the
ExternalName mirrors in the computing-unit namespace all go through the helpers now.

The chart-generated S3 credentials Secret gets a fixed name for the same reason:
values-aws.yaml wires it into lakefs.extraEnvVars and carried a note telling the
reader to hand-edit both name: fields when the release is not called texera. That
note is no longer needed and has been dropped.

One consequence worth calling out for reviewers: the pinned names make the chart
release-name independent, but they also mean two Texera releases can no longer coexist in
a single namespace. That was already effectively true — workflowComputingUnitPool.namespace
and the ExternalName mirrors collide between releases regardless, and values.yaml
already warns about it — so this codifies an existing constraint rather than adding one.

Any related issues, documentation, discussions?

No separate issue was filed; the problem was found while writing cluster deployment
notes for the chart. Comments in values.yaml, values-aws.yaml and _helpers.tpl are
updated in this PR to explain why the names are pinned, so the constraint is documented
where someone would next be tempted to un-pin it.

How was this PR tested?

The chart has no automated render tests, so this was verified by rendering and diffing.

1. Existing deployments are unaffected — release texera renders byte-identically.
Rendered helm template texera bin/k8s before and after the change, for all three values
files, and diffed (filtering only Lakekeeper's encryptionKey, which the sub-chart
regenerates randomly on every render):

IDENTICAL  release=texera  values.yaml
IDENTICAL  release=texera  values-aws.yaml
IDENTICAL  release=texera  values-development.yaml

2. The bug is fixed for other release names. A script parses the rendered manifests,
base64-decodes Secret values (so LAKEKEEPER__PG_HOST_* and the LakeFS connection string
are visible), collects every reference to a *-postgresql / *-minio /
*-s3-credentials object, and checks each one against the set of resources the render
actually creates:

===== BASELINE (main) =====
DANGLING  release=myrel
            -> texera-minio        (referenced, never created)
            -> texera-postgresql   (referenced, never created)

===== AFTER FIX =====
CLEAN  release=texera / myrel / other-name   x   values.yaml, values-aws.yaml, values-development.yaml

All nine combinations (3 release names x 3 values files) render with no dangling
references, and helm lint passes.

Not covered: this is a static render check, so it verifies the names now agree; it does
not exercise a live LakeFS/Lakekeeper connection under a non-texera release. Given the
only change is which hostname string is emitted, and release texera is unchanged, an
in-cluster run seemed disproportionate — happy to add one if a reviewer prefers.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 5

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. release/* labels drive the post-merge backport, so add or remove one to change where this fix lands.

Release branch	Analysis
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7.

Auto-label run.

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @bobbai00, @mengw15, @tanishqgandhi1908
  You can notify them by mentioning @bobbai00, @mengw15, @tanishqgandhi1908 in a comment.