fix: Mount the writable emptyDir file into the nextcloud container directly

[edvinas31]

Description of the change

Mount the writable php-confd emptyDir over /usr/local/etc/php/conf.d/redis-session.ini in the main nextcloud container, guarded by .Values.redis.enabled.

When redis.enabled=true the chart already creates everything needed for this:

a php-confd emptyDir volume (deployment.yaml, volumes section), an init-redis-session-ini init container that mounts that volume at /usr/local/etc/php/conf.d and touches redis-session.ini into it, using the Nextcloud image so the file is owned by the right UID, and a subPath mount of that file into the nextcloud-cron sidecar.

The one container that actually needs it - the main nextcloud container, whose entrypoint writes the file - was never given the mount. This adds it, mirroring the existing block in the cron sidecar.

Benefits

Fixes /entrypoint.sh: cannot create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied when running the main container as non-root (e.g. nextcloud.securityContext.runAsUser: 33) with Redis enabled. /usr/local/etc/php/conf.d inside the image is root-owned, so the entrypoint's "Configuring Redis as session handler" step fails for any non-root user; the emptyDir the chart already provisions makes the single file writable without shadowing the rest of conf.d.

Users currently have to work around this in their own values with:

nextcloud:
  extraVolumeMounts:
    - name: php-confd
      mountPath: "/usr/local/etc/php/conf.d/redis-session.ini"
      subPath: redis-session.ini

which reaches into a chart-internal volume name. That workaround becomes unnecessary.

Possible drawbacks

Anyone using the extraVolumeMounts workaround above will get a duplicate mountPath on the nextcloud container, which the API server rejects, until they remove it from their values. Worth a release note.
The mount stays gated on .Values.redis.enabled, consistent with the volume and the init container. externalRedis.enabled=true sets REDIS_HOST too, so it hits the same entrypoint path and the same permission error, but the volume and init container don't exist in that case - fixing external Redis means widening all four conditions and is left out of this PR deliberately.

Applicable issues

relates to #187 - the original fix for this error; it covered the cron sidecar but not the main container
relates to #814 - same error reported on RKE2 with a non-root securityContext (closed without a chart-side fix)

Additional information

Verified with helm template on the local chart:

redis.enabled=true, cronjob.enabled=true, nextcloud.securityContext.runAsUser=33 → the mount renders exactly once in the nextcloud container and once in nextcloud-cron; no duplicate mountPath in any container
redis.enabled=false → no php-confd references anywhere in the rendered Deployment
helm lint passes
No new or changed values, so no README changes are needed.

Checklist

• I have read the CONTRIBUTING.md doc.
• DCO has been signed off on the commit.
• Chart version bumped in Chart.yaml according to semver.
• (optional) Parameters are documented in the README.md