FeatureStoreServices needs PodLabels, ServiceAccountName, and a way to override the container command

[dbbvitor]

Is your feature request related to a problem? Please describe.

Yes, in three related ways — FeatureStoreServices doesn't expose enough customization for the Deployments/pods the Operator creates:

#	Gap	Consequence
1	No Command/Args override on ServerConfigs	Can't wrap the feast binary (OTel, profiling) without renaming it inside a custom image
2	PodAnnotations exists, no parallel PodLabels	A pod label our log collector needs has no CRD-native way in
3	No ServiceAccountName override anywhere	Can't run under a pre-existing IRSA/Vault-annotated SA — and breaks the Operator's own RBAC grants (e.g. for spark_application) once anything swaps the pod's identity out from under it

The container command is built by getContainerCommand() from a fixed baseCommand constant, then assigned to Command: cmd — no override hook, so the standard "wrap the entrypoint" pattern for zero-code instrumentation does nothing.

We work around all three today via a Kyverno ClusterPolicy (patches serviceAccountName, a Vault annotation, and a pod label onto every FeatureStore-owned Deployment) plus a Dockerfile-level binary-renaming shim for (1.) — functional, but each is a maintenance burden that a few CRD fields would remove entirely.

Describe the solution you'd like

// ServerConfigs
Command []string `json:"command,omitempty"`
Args    []string `json:"args,omitempty"`

// FeatureStoreServices
PodLabels          map[string]string `json:"podLabels,omitempty"`
ServiceAccountName *string           `json:"serviceAccountName,omitempty"`

• Command/Args: when set, the Operator uses them verbatim instead of getContainerCommand()'s computed default — the same direct override Kubernetes itself exposes on every container.
• PodLabels: parallel to the existing PodAnnotations, merged onto the pod template the same way.
• ServiceAccountName: when set, used directly on every Deployment/Pod for that FeatureStore instead of auto-creating one; any Operator-side RBAC (e.g. SparkApplication CRUD) binds to the effective name rather than assuming the auto-created one.

All three are direct pass-throughs of existing Kubernetes container/pod fields — consistent with how this CRD already exposes VolumeMounts, Tolerations, and NodeSelector.

Describe alternatives you've considered

The Kyverno ClusterPolicy + Dockerfile binary-rename shim described above — both work, but neither self-heals cleanly (the Kyverno policy has skipBackgroundRequests: true, so a bug in it stays live on already-running Deployments until something else forces a reconcile — we've been bitten by this once already), and the ServiceAccountName workaround specifically has a blast radius: SparkApplication-owned pods, outside any FeatureStore-scoped mutation, need a fully separate IRSA identity of their own as a result.

Additional context

Test plan

• A ServerConfigs.Command override is used verbatim on the container spec; omitting it preserves today's computed command exactly.
• PodLabels renders on the Deployment's pod template, merged the same way as PodAnnotations.
• ServiceAccountName overrides spec.template.spec.serviceAccountName with no ServiceAccount object auto-created; Operator-side RBAC (e.g. SparkApplication CRUD) binds to the effective name.