Feature request: Add Kubernetes scale subresource support for Dragonfly CRD

Hi DragonflyDB team,

I would like to request support for the Kubernetes /scale subresource on the Dragonfly CRD.

Currently, the Dragonfly CRD does not expose a scale subresource, so HPA/KEDA cannot safely target the Dragonfly custom resource directly. The available workaround is to target the operator-generated StatefulSet, but that can cause the autoscaler and Dragonfly Operator to both manage replica count, which may lead to unstable reconciliation.

It would be helpful if the CRD supported something like:

subresources:
scale:
specReplicasPath: .spec.replicas
statusReplicasPath: .status.replicas
labelSelectorPath: .status.selector

This would allow autoscalers such as HPA/KEDA to update Dragonfly.spec.replicas while keeping the Dragonfly Operator as the single owner of StatefulSet reconciliation, role labels, failover, and replica lifecycle.

Example desired usage:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: dragonfly-autoscaler
spec:
scaleTargetRef:
apiVersion: dragonflydb.io/v1alpha1
kind: Dragonfly
name: example-dragonfly
minReplicaCount: 3
maxReplicaCount: 8

Use case: scaling Dragonfly replicas for read-heavy workloads where replicas are used to serve read traffic, while preserving operator-managed topology and failover behavior.

Thanks for considering this feature.

Start by locating the Dragonfly CRD definition and the operator reconciliation path that manages its StatefulSet and replica status. Implement the /scale subresource using the stated spec, status, and selector paths, then verify that HPA/KEDA can update Dragonfly.spec.replicas without conflicting with operator-managed reconciliation.

Written by the indexing model from the issue text.