Helm chart defaults don't work: storage mounts, service names, storage class, migration schedule #2695

A default install of k8s/exceptionless (no connection strings set) does not work end to end. The chart's fallback Elasticsearch and Redis services don't match the connection strings it generates, the event-posts job can't read posted events from the default folder storage, the storage claim targets an Azure-only class, and the "manual only" migration CronJob is scheduled to run.

Rendered with helm template ex k8s/exceptionless at c6583c1.

Checklist

• event-posts (and other storage jobs) don't mount the storage volume. With storage.connectionString unset, the chart uses provider=folder;path=/app/storage (config.yaml L39) and mounts the claim only in the app, API and work-item pods. The event-posts deployment has no volume, so EventPostsJob looks for payloads in its own empty /app/storage and every posted event fails with "Unable to retrieve payload". The cleanup-data and download-geoip-database CronJobs also use IFileStorage and have no mount. (Reported earlier in [Suggestion]EventPostsJob throw an error "Unable to retrieve payload ...." when Depolyed on K8s #580, closed without a chart change.)
• Default Elasticsearch connection string points at a service the chart doesn't create. config.yaml L33 defaults to server=http://elasticsearch:9200, but the fallback service is named <fullname>-elasticsearch (elasticsearch.yaml L92-L95). Rendered: server=http://elasticsearch:9200 vs service ex-elasticsearch.
• Default Redis connection string points at a service the chart doesn't create. config.yaml L34-L35 generates <fullname>-redis-master, but the fallback service is <fullname>-redis (redis.yaml L36-L39). Rendered: ex-redis-master,abortConnect=false vs service ex-redis.
• Storage claim is Azure-only and can't be satisfied as written. storage.yaml hardcodes storageClassName: managed-csi-premium, which only exists on AKS, so the claim stays Pending elsewhere. On AKS that class is Azure Disk, which doesn't support ReadWriteMany filesystem volumes, so the ReadWriteMany claim can't bind there either.
• "Never" migration CronJob runs every Monday in February. jobs.yaml L420 uses schedule: "0 0 29 2 1" # never, only manually. When both day-of-month and day-of-week are restricted, cron runs when either matches, so this fires at midnight on Feb 29 and on every Monday in February.

Expected

helm install with default values produces a working instance: jobs connect to the bundled Elasticsearch and Redis, posted events are processed, the claim binds on a typical cluster, and the migration job only runs when triggered.

Suggested fix

• Mount the storage claim in every job that uses file storage (event-posts, cleanup-data, download-geoip-database), ideally through a shared helper in _helpers.tpl.
• Default the Elasticsearch connection string to server=http://{{ fullname }}-elasticsearch:9200 and the Redis one to {{ fullname }}-redis,abortConnect=false.
• Add storage.storageClassName (empty by default, so the cluster default is used) and storage.accessModes/storage.size values. Document that a ReadWriteMany-capable class (NFS, Azure Files, EFS) or an object-storage connection string is needed when pods run on more than one node.
• Mark the migration CronJob suspend: true (keeping a valid schedule) so it only runs via kubectl create job --from=cronjob/....