Helm chart: support multiple file-ref Secrets via a projected secrets volume

## Problem

`FileRefBackend` resolves every secret ref against a **single** root (`KDIVE_SECRETS_ROOT`, default `/etc/kdive/secrets`). The Helm chart mounts exactly **one** pre-existing Secret into that root as a plain `secret:` volume:

- `deploy/helm/kdive/values.yaml:52-54` — `secrets.secretName` / `secrets.mountPath`
- `deploy/helm/kdive/templates/_helpers.tpl:113-140` — `kdive.secretsEnv` / `kdive.secretsVolumeMount` / `kdive.secretsVolume`

Because there is one root and one Secret volume, **all** file-ref credentials must live in the same Secret. Today that means an SSH build-host key (`build_hosts.register_ssh` `ssh_credential_ref`) has to be co-located in `kdive-remote-tls` alongside the remote-libvirt TLS PEMs — there is no way to supply it as an isolated, separately-managed Secret.

This surfaced while adding a dedicated SSH build host (`dave@kdive.pdx.drc.nz`): the build-host key and the libvirt TLS material want different lifecycles/owners, but the chart forces them into one Secret. We took the co-locate path for now; this issue tracks the isolation enhancement.

## Proposal

Rework the secrets-volume helpers so multiple Secrets project into the single secrets root:

- Replace the single `secret:` volume in `kdive.secretsVolume` with a `projected:` volume whose `sources` fan one-or-more Secrets into `mountPath`, so each Secret's keys appear as files under the one `KDIVE_SECRETS_ROOT`.
- Extend `values.yaml` to accept a list of secret sources (e.g. `secrets.sources: [, ...]`), keeping a single mount path. Per the "replace, don't deprecate" standard, prefer migrating `secrets.secretName` to the list form over carrying both shapes.
- `KDIVE_SECRETS_ROOT` / `mountPath` semantics are unchanged; refs stay root-relative filenames.

## Constraints / notes

- One secrets root only — every source projects into the same directory, so **file-key names must be unique across the listed Secrets** (document and, if cheap, fail-fast on collision).
- Mount into server + worker + reconciler (all three already include the secret helpers).
- A chart-version bump re-rolls the bundled demo's `emptyDir` backends (postgres/minio + `minio-init` immutability) — plan the demo redeploy as a clean reinstall, not an in-place upgrade.

## Needs

- ADR for the multi-source secrets-volume decision (projected volume + list-shaped values).
- Chart template tests covering: zero sources (renders nothing), one source (back-compat with today's single mount), multiple sources (projected volume with N entries).

## Acceptance criteria

- Operator can supply two independent Secrets (e.g. `kdive-remote-tls` for libvirt PEMs and a dedicated `kdive-build-ssh` for the build-host key) and both resolve as file refs under `/etc/kdive/secrets`.
- `helm template` renders a projected volume with the listed sources; existing single-Secret deploys keep working after the values migration.
- Docs updated (`values.yaml` comments + the relevant operating/secrets doc).

## Out of scope

- Registering the SSH build host itself (`build_hosts.register_ssh`) — that is the ops path and does not depend on this.
- Non-file secret backends (S3/Vault/etc.); this stays within the file-ref model.