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

Yes — FeatureStoreSpec.Replicas and FeatureStoreServices.Scaling (HPA autoscaling) are single
knobs for the entire FeatureStore CR, and three CEL rules on
featurestore_types.go
gate them — confirmed identical on current master and in our own vendored CRD manifest (Feast
0.66.0):

- message: Scaling requires DB-backed persistence for the online store.
  rule: >
    self.replicas <= 1 && !has(self.services.scaling.autoscaling) ||
    (has(self.services.onlineStore) && has(self.services.onlineStore.persistence.store))
- message: Scaling requires DB-backed persistence for the offline store.
  rule: >
    self.replicas <= 1 && !has(self.services.scaling.autoscaling) ||
    (!has(self.services.offlineStore) || has(self.services.offlineStore.persistence.store))
- message: Scaling requires DB-backed or remote registry.
  rule: >
    self.replicas <= 1 && !has(self.services.scaling.autoscaling) ||
    (has(self.services.registry) && (has(self.services.registry.remote) || ...))

(simplified for readability — the actual rules also null-check self.services itself; full text
in featurestore_types.go)

The offline rule gets this right — !has(...offlineStore) || <DB-backed> — absent or
qualifying, either is fine. The online and registry rules don't: both require
has(self.services.) unconditionally, with no escape for the service simply not
being configured.

That matters because Feast supports standalone, single-purpose FeatureStores: a registry-only
store, an offline-only store, a UI-only or MCP-only store (MCP rides on the registry's REST API,
so it inherits the registry rule's gap too). Omitting the onlineStore block, or setting
OnlineStore.Disabled (added in 0.66.0 as the sanctioned way to skip the online server), are both
legitimate ways to run one of these shapes — but neither satisfies the online rule, and an absent
registry never satisfies the registry rule. So a CR that runs nothing but a stateless registry
(or offline store, or UI/MCP server) can't enable autoscaling, purely because of services it was
never running in the first place.

We already run exactly this shape in production — a registry-only CR, its own Deployment, no
online or offline server at all — it just can't be an HPA target today.

Describe the solution you'd like

Mirror the offline rule's shape on the other two:

# online rule, add the escape:
!has(self.services.onlineStore) || self.services.onlineStore.disabled || <existing DB-backed check>

# registry rule, add the escape:
!has(self.services.registry) || <existing remote-or-DB-backed check>

This uses the CR's existing services.scaling/replicas field as-is — no new schema. A
standalone registry-only, offline-only, or UI/MCP-only CR would then pass validation instead of
being penalized for services it never configured.

Describe alternatives you've considered

Splitting Replicas/Scaling into separate fields on OnlineStore/OfflineStore/Registry —
rejected: the Operator already packs a CR's enabled services as sibling containers in one pod, so
replica count is inherently a whole-CR property once more than one service shares a CR.
Independent scaling already comes from running one CR per standalone server (the same pattern
that gives each service its own Deployment/Service/FQDN today) — the CEL rules above are the only
thing stopping that pattern from validating.