Feast Operator fails when deployed to custom namespace - requires "feast-operator-system" to exist

## Expected Behavior
The operator should function correctly regardless of which namespace it is deployed in. It should not require `feast-operator-system` to exist when running in a different namespace.

## Current Behavior
The operator fails to fully reconcile FeatureStore CRs because it attempts to access resources in `feast-operator-system`, which doesn't exist when the operator is deployed elsewhere.

## Steps to reproduce
1. Deploy the Feast Operator to a custom namespace instead of `feast-operator-system`
2. Verify the operator is running:
kubectl get pods -n test
# feast-operator-controller-manager-xxx 1/1 Running
3. Create a FeatureStore CR in any namespace
4. Check the FeatureStore status:
kubectl describe feast -n
5. Observe the failure:

## Workaround

Creating an empty `feast-operator-system` namespace resolves the issue:

kubectl create namespace feast-operator-system.After this, FeatureStore CRs reconcile successfully and show `Ready` status.

## Suggested Fix

The operator should dynamically determine its own namespace (using Kubernetes Downward API or ServiceAccount namespace) instead of assuming it runs in `feast-operator-system`.

### Specifications

- Version: 0.54.0