feat: first-class encrypted user values — kept out of committed node files, honored at both template and apply #221

Summary

talm already encrypts its fixed secret set (secrets.yaml, talosconfig,
kubeconfig) with the age key in talm.key. There is, however, no first-class
way to handle arbitrary user secret values that templates consume. As a
result such secrets either land in git in plaintext, or cannot be supplied at
apply time at all.

Use case

We inject secrets into the machine config that must be (a) stored encrypted
at rest in git and (b) never present in plaintext in committed rendered
node files. Concrete examples:

• a KMS plugin's Vault AppRole secret-id (passed as env to a static pod in
  machine.pods);
• a private registry password (RegistryAuthConfig).

These are real secret values referenced by chart templates — not Talos' own
PKI/tokens that talm.key already covers.

Current behavior / gaps

1. Put the secret in values.yaml → committed in plaintext.
2. Put it in a separate values file referenced by templates → talm template
   honors templateOptions.valueFiles, but talm template -I then bakes the
   secret into the committed nodes/*.yaml in plaintext.
3. talm apply re-renders from the template (per the modeline, see bug(apply): node file content silently discarded when modeline contains templates= #126) using
   values.yaml only — it does not honor templateOptions.valueFiles
   and has no --values / --set-file. So a value supplied only via a value
   file is lost at apply (renders empty / required fails), even though it
   rendered fine under talm template. This template↔apply inconsistency is the
   core blocker.

Current workaround (and why it's awkward)

We keep all secret-bearing config out of the chart and pass it as a SOPS-
encrypted side-patch: talm apply -f nodes/cpN.yaml -f secret-patch.yaml.
Downsides:

• list fields (machine.pods, cluster.apiServer.extraVolumes) concatenate
  across layers, so the resource must live in exactly one layer — we can't
  template the static pod and inject just the creds via a patch (it duplicates);
• the side-patch ends up duplicating otherwise-static config;
• it's a manual, easy-to-forget extra -f.

Proposal (any one would solve it)

1. Honor valueFiles at apply (and add --values / --set-file) so
   values are consistent between talm template and talm apply.
2. Native encrypted user values: extend the existing age workflow to an
   arbitrary user values file, e.g. values-secret.yaml ↔
   values-secret.encrypted.yaml (committed), decrypted via talm.key for both
   template and apply. This mirrors how secrets.yaml already works.
3. Keep secret values out of committed rendered node files — e.g. a way to
   mark values as secret so talm template -I writes a placeholder while the
   real value is injected only at apply.

Environment

• talm v0.31.0, Talos v1.13, multi-doc render path.
• Related: bug(apply): node file content silently discarded when modeline contains templates= #126 (apply re-renders from template per modeline), talm apply: redact secret values in drift preview output #189 (redact
  secrets in drift output).