fix: generate a per-deploy HyperDX session secret

[catinspace-au]

Two HyperDX keys the chart never set.

HyperDX falls back to a session secret published in upstream's source when EXPRESS_SESSION_SECRET is unset (packages/api/src/config.ts:16 in our fork, upstream 2.40.0), so every Kubernetes deployment signed HyperDX sessions with the same public key. And without TOKEN_ENCRYPTION_KEY it stores third-party tokens (Slack bot tokens, OAuth tokens) in plain text.

• templates/generated-keys.yaml: one ESO Password generator plus ExternalSecret per key.
  • dfe-hyperdx-session / session-secret: the 48-char alphanumeric password itself.
  • dfe-hyperdx-token-encryption / token-encryption-key: {{ .password | sha256sum }}, 64 hex chars. The fork takes 64 hex chars or base64 of exactly 32 bytes and refuses to start on anything else (packages/api/src/utils/tokenEncryption.ts:150). ESO 2.10.0's template sha256sum returns hex.EncodeToString(sha256.Sum256(...)) (runtime/template/v2/sprig/crypto.go).
• The pod reads both through secretKeyRef.
• Stable across Argo syncs: refreshPolicy: CreatedOnce + refreshInterval: "0", so ESO writes each value once and a re-render or re-label never rotates it. Nothing is minted at render time, so helm template output is byte-identical every time. helm.sh/resource-policy: keep stops an uninstall taking either key with it. Rotation matters most for the token key: a new one makes every stored token unreadable.
• sessionSecret.create: false / tokenEncryption.create: false hand the Secret to the deployment; the pod still reads it.
• ESO is already a prerequisite of every mode that runs hyperdx (ferretdb's password and the engine JWT use the same generator).
• dfe-stack's README and NOTES list both keys among the ESO-generated secrets.

Tests: test_render_stable.py covers both keys -- the default renders the generator and a CreatedOnce ExternalSecret with the exact value template, renders identically twice and wires the pod to it; create=false renders neither and the pod still reads the Secret.

The pinned HyperDX image (v0.2.7) reads EXPRESS_SESSION_SECRET today. It predates tokenEncryption.ts, so TOKEN_ENCRYPTION_KEY takes effect from the first fork release that carries it.

The compose half is hyperi-io/dfe-docker#204.

Done when CI is green and a fresh deploy's hyperdx pod starts with both keys from their minted Secrets.