What this PR does / why we need it:

This PR adds spec.feastProjectDir.packaged, allowing the Feast Operator to use a feature repository packaged inside a container image.

The Operator currently supports creating a feature repository through git clone or feast init. In air-gapped and artifact-based deployment environments, feature definitions and their Python dependencies are commonly distributed as an immutable container image. The existing workflow requires disabling init containers, configuring images separately for each service, and coordinating feast apply through a separate CI/CD, CronJob, or manual workflow. It also does not provide a first-class way to declare where the packaged repository is located in the image. Therefore a failed feast apply is surfaced only after the rollout, allowing a service to start against stale or missing definitions

The new packaged repository mode accepts:

• image: the image containing the feature repository.
• featureRepoPath: the absolute path to the repository inside that image.

It supports two lifecycle modes:

1. [packaged objects + CR-generated YAML]
   With init containers enabled, feast-init copies the packaged repository into the Operator-managed shared directory, replaces its feature_store.yaml with the configuration generated from the FeatureStore CR, and feast-apply registers the definitions before the Feast services start.
2. [packaged image as is]
   With init containers disabled, services run directly from the packaged repository path and use its baked feature_store.yaml.

The packaged image is used by default for repository initialization, feast apply, and Feast services. Explicit per-service images continue to take precedence.

This enables:

• Air-gapped deployments without runtime access to a Git repository.
• An invalid path, missing repository, or failed feast apply is surfaced during pod initialization
• Reproducible promotion of feature definitions and their Python dependencies as one immutable artifact.
• Separation between teams publishing feature definitions and teams managing environment-specific FeatureStore CR configuration through GitOps.
• Consistent dependencies across repository initialization, feast apply, and feature serving.
• Reduced image configuration duplication across Feast services.

The existing git and init repository modes remain unchanged.

Which issue(s) this PR fixes:

N/A — no linked issue.

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests
• Manual tests
• Testing is not required for this change

Focused Feast Operator controller tests:

GOWORK=off KUBEBUILDER_ASSETS=<envtest-assets> go test ./internal/controller -count=1

The controller test suite covers:

• Staging a packaged repository and applying it from the shared directory.
• Direct use of the packaged repository when init containers are disabled.
• Packaged-image precedence and explicit per-service image overrides.
• Fallback behavior when the packaged image is omitted.
• Validation of absolute, non-root repository paths.
• Mutual exclusivity between packaged, git, and init.