Is your feature request related to a problem? Please describe.
We need to run the Fluent Bit node agents in a dedicated namespace with relaxed Pod Security Standards (privileged) while keeping the control plane pieces (operator, aggregators, CRDs) in a restricted control namespace. Today, Fluent Bit resources are created in spec.controlNamespace, which:

• Forces mixing privileged and restricted policies in one ns
• Complicates RBAC/ownership boundaries for platform vs. app teams
• Makes PSA/WL segregation and tenancy policy enforcement harder

Describe the solution you'd like
Add a new field to the Logging CRD: spec.nodeAgentNamespace (string).

• When set, all Fluent Bit resources (DaemonSet, ServiceAccount, Roles/Bindings, Services, ServiceMonitors) are reconciled into spec.nodeAgentNamespace
• Defaults to spec.controlNamespace to preserve backward compatibility
• Field is immutable (same XValidation rule as controlNamespace)
• RBAC subjects for Fluent Bit bindings use the agent namespace
• Works for both legacy spec.fluentbit and standalone FluentbitAgent resources

Example:

apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: infra
spec:
  loggingRef: infra
  controlNamespace: logging
  nodeAgentNamespace: logging-node-agents
  fluentd:
    disablePvc: true
---
apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: infra
spec:
  loggingRef: infra

Tests:

• E2E that asserts:
  • Fluentd pods exist in controlNamespace
  • Fluent Bit DaemonSet pods exist in nodeAgentNamespace
  • Logs reach the test receiver

Describe alternatives you've considered

• Deploy a separate, manually managed Fluent Bit DaemonSet outside the operator (loses reconciliation/consistency)
• Use multiple Logging resources (one per namespace) to split concerns (more complex; duplicates config/state)
• Keep everything in controlNamespace and relax PSA there (security trade-off, undesired in many orgs)
• Use FluentbitAgent only and keep controlNamespace for Fluent Bit too (same PSA issue)

Additional context

• Backward compatible: default equals controlNamespace
• Clean RBAC story: ClusterRole/Binding remains cluster-scoped, ServiceAccount lives in agent ns
• E2E reference available (validates placement and end-to-end delivery);
• This also clarifies ownership: platform team manages controlNamespace; node agents can be delegated to infra/ops