Helm: built-in MinIO runs on default credentials, so the generated STORAGE_CONFIG can never authenticate

## Summary

With the built-in MinIO (the default), `helm/huly/templates/secret.yaml` generates

```
minio|minio?accessKey=&secretKey=
```

but `helm/huly/templates/minio/deployment.yaml` sets no `MINIO_ROOT_USER` / `MINIO_ROOT_PASSWORD`,
so MinIO starts on its built-in `minioadmin:minioadmin`. The generated keys therefore do not exist
in MinIO, and every Huly service that talks to storage authenticates with credentials MinIO
rejects.

`compose.yml` gets this right by using the credentials MinIO actually has:

```yaml
- STORAGE_CONFIG=minio|minio?accessKey=minioadmin&secretKey=minioadmin
```

The Helm chart generates random ones instead, without giving MinIO a matching root user.

## Evidence

**1. The rendered MinIO container has no root credentials.** From a running deployment of this
chart (only image defaults, which point at `/run/secrets/...` files that do not exist):

```console
$ kubectl exec deploy/minio -- env | grep -i '^MINIO_ROOT'
MINIO_ROOT_USER_FILE=access_key
MINIO_ROOT_PASSWORD_FILE=secret_key
```

**2. MinIO says so itself:**

```console
$ kubectl logs deploy/minio | grep -i 'default credentials'
WARN: Detected default credentials 'minioadmin:minioadmin', we recommend that you change these
values with 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' environment variables
```

**3. The generated credentials are rejected.** `minio/minio` started exactly as the chart starts it
(`server /data --address :9000`, no root env), then queried with the access/secret key pair from an
actual `helm template` render of this chart:

```console
$ curl --aws-sigv4 "aws:amz:us-east-1:s3" -u ":" http://127.0.0.1:9000/
HTTP 403
InvalidAccessKeyIdThe Access Key Id you provided does not exist in our records.

$ curl --aws-sigv4 "aws:amz:us-east-1:s3" -u "minioadmin:minioadmin" http://127.0.0.1:9000/
HTTP 200
```

So a default `helm install` produces a Huly that cannot read or write object storage — uploads,
avatars and attachments fail — unless the operator overrides `secrets.storageConfig` with
`minio|minio?accessKey=minioadmin&secretKey=minioadmin` by hand.

## Proposed fix

Give MinIO the credentials the chart is already writing into `STORAGE_CONFIG`, rather than deriving
`STORAGE_CONFIG` from MinIO's undeclared defaults:

- add `minio.rootUser` / `minio.rootPassword` (defaulting to `minioadmin` / `minioadmin`);
- inject them into the MinIO deployment as `MINIO_ROOT_USER` / `MINIO_ROOT_PASSWORD`;
- build the default `STORAGE_CONFIG` from the same pair.

Defaulting to MinIO's built-ins keeps every existing install working — that pair is what deployed
MinIO instances are running with today — while making the credentials configurable for the first
time and removing the mismatch. Passing them through the Secret rather than hardcoding them was the
least invasive option that also lets an operator move off default credentials.

One extra guard is included: MinIO refuses to start if the root user is under 3 characters or the
password under 8 (`FATAL Unable to validate credentials inherited from the shell environment`), so
the chart fails at template time instead of leaving a CrashLoopBackOff to diagnose.

## Environment

ArgoCD-managed Kubernetes, chart from `main` (`8655845`), Helm 3.20.0, `minio/minio` (current
`latest`, digest `sha256:14cea493d9a34af32f524e538b8346cf79f3321eff8e708c1e2960462bd8936e`).

Start by comparing helm/huly/templates/secret.yaml with helm/huly/templates/minio/deployment.yaml, then use compose.yml as the working credential reference. Render the chart with helm template and verify that the MinIO root credentials and STORAGE_CONFIG use the same pair, including the stated minimum-length validation; a default install should authenticate successfully without manual overrides.

Written by the indexing model from the issue text.