Set fsGroup for RavenDB pods

[jkossis]

Summary

• Set pod-level fsGroup to 999 for generated RavenDB StatefulSets
• Use OnRootMismatch fsGroupChangePolicy to avoid unnecessary recursive ownership changes
• Add unit coverage for the generated pod security context

Use case

The operator runs the RavenDB container as UID/GID 999, but the generated pod security context currently only sets the low-port sysctl and does not set fsGroup. On storage providers such as Longhorn, a freshly provisioned PVC can be mounted with ownership that UID/GID 999 cannot write to. RavenDB then fails during startup with a data directory permission error such as:

Could not access some of the specified paths.
Key: 'DataDir' Path: '/var/lib/ravendb/data'
Error: 'Access to the path ... is denied.'

Setting fsGroup to the same group used by the RavenDB container lets Kubernetes prepare mounted volumes for the non-root process. In a live Longhorn-backed cluster, patching the StatefulSet with fsGroup: 999 and restarting the pod resolved the DataDir permission failure and allowed the cluster bootstrap job to complete.

Validation

• go test ./pkg/resource
• go test ./pkg/...

Note: go test ./api/... ./pkg/... could not complete locally because the api/v1 envtest suite requires /usr/local/kubebuilder/bin/etcd, which is not installed in this environment. The pkg tests all pass.

[jkossis]

@TheGoldenPlatypus tagging for visibility