What this PR does / why we need it:

When deploying Feast via the Feast Operator, users must manually run feast apply
after every CRD creation to populate the feature store registry. This is an extra
operational step that is easy to forget and creates a poor user experience.

• This PR adds a feast-apply init container to the Feast deployment that runs feast apply
  automatically before the main server containers start. This ensures the registry is
  always populated on every pod start. The init container inherits env vars, envFrom, and volume mounts from all configured server containers (registry, online, offline) to ensure DB/store connectivity.

Users can set spec.services.runFeastApplyOnInit to false to disable the automatic apply behavior. The feature can also be disabled globally via the existing spec.services.disableInitContainers: true field.

• Surface container failure details in CRD status when the deployment is unavailable. Instead of the generic "Deployment is not available", the controller now inspects pod init/container statuses and reports the specific failure (e.g., Init container 'feast-apply' failed with exit code 1).

• Fix _apply_object race condition in SqlRegistry by wrapping the insert in a savepoint and catching IntegrityError, so concurrent feast apply calls from multiple pods don't crash on duplicate key conflicts. This was done to fix intermittent failures on rest-api tests.

• Make replicas field optional in the FeatureStore CRD spec (json:"replicas,omitempty"), removing it from the required list so it defaults to 1 without requiring explicit specification.