feat: pass fieldRef/resourceFieldRef env vars through to container Env instead of rejecting them

[coderabbitai]

Summary

Currently, the operator's resolveEnvVarValue function (in kubernetes/operator/internal/controller/env.go) returns an error when a CR spec env entry uses fieldRef or resourceFieldRef. This breaks the existing corev1.EnvVar contract for users who rely on the Downward API.

Background

PR #1753 moved all env var resolution to reconcile-time so values are embedded in the .env file rather than passed through to container.Env. However, fieldRef and resourceFieldRef are runtime-only sources that are only meaningful inside a running pod — they cannot be resolved at reconcile time. The safe handling is to leave them in Deployment.Spec.Template.Spec.Containers[*].Env unchanged, letting the kubelet resolve them at runtime.

Desired Behavior

• fieldRef and resourceFieldRef entries in spec.env should not be added to the .env file.
• Instead, they should be passed through as-is into the pod template's container.Env so the kubelet can resolve them at runtime.
• All other ValueFrom types (secretKeyRef, configMapKeyRef) continue to be resolved at reconcile time and written to the .env file only.

Files Affected

• kubernetes/operator/internal/controller/env.go — remove error returns for FieldRef / ResourceFieldRef in resolveEnvVarValue
• kubernetes/operator/internal/controller/openrag_controller.go — update buildBackendEnv / buildLangflowEnv / Deployment construction to pass these entries into container.Env

References

• PR: fix: operator only contain env variables in dot env #1753
• Review comment: fix: operator only contain env variables in dot env #1753 (comment)
• Requested by: @zzzming