feat(chart): add opt-in enableInTreeAutoscaling support #35

Feature description

Summary

Adds an opt-in autoscaling.enabled value that wires Ray's in-tree autoscaler into the RayCluster spec. Default is off — chart output is byte-identical to today's behaviour for existing consumers.

Changes

chart/values.yaml — new top-level autoscaling: block with enabled, idleTimeoutSeconds, upscalingMode, resources. All defaults preserve today's static-scaling behaviour.
chart/templates/rayservice.yaml — conditional enableInTreeAutoscaling: true + autoscalerOptions block, gated on .Values.autoscaling.enabled.
chart/Chart.yaml — minor bump 0.4.1 → 0.5.0 for the new feature.
README.md — four new rows in the values table documenting the block.

Backwards compatibility

Default autoscaling.enabled: false. Rendered manifests for any existing values file are unchanged — the new conditional emits nothing when disabled.

Test plan

• Deploy chart with autoscaling.enabled: false (default) → rendered RayService is byte-identical to pre-PR output. Confirmed via helm template diff.
• Deploy chart with autoscaling.enabled: true, worker.minReplicas: 1, worker.maxReplicas: 6 → RayCluster spec has enableInTreeAutoscaling: true + autoscalerOptions; head pod gets the autoscaler sidecar container; worker count scales up when tasks are submitted and back down after idleTimeoutSeconds.
• Override autoscaling.resources → sidecar container resources reflect the override.
• References
• KubeRay autoscaling guide
• Ray Serve K8s production guide — recommends enabling K8s + Ray autoscaling in production

Value and/or benefit

The gap this closes

The chart already exposes worker.minReplicas and worker.maxReplicas, and the README values table labels both "for autoscaling". But the RayCluster template never emits enableInTreeAutoscaling: true, so KubeRay ignores those fields and always deploys exactly worker.replicas count of workers. The result is that setting minReplicas / maxReplicas has no observable effect today.

This PR wires the missing top-level flag through a new autoscaling: values block. When autoscaling.enabled: true: #27

Chart renders enableInTreeAutoscaling: true on the RayCluster spec
KubeRay attaches an autoscaler sidecar to the head pod
The already-existing worker.minReplicas and worker.maxReplicas become the scaling range
autoscalerOptions.idleTimeoutSeconds and .upscalingMode are configurable via the new block (defaults per Ray docs: 60 s and Default)

Real-world motivation

We hit this while sizing a Ray cluster for a Nebari deployment. The user needed 3+ CPUs on the Ray cluster (checkmaite reserves CPUs for its registry + per-job controller actors before any worker task can be placed). Static bump of worker.replicas unblocked them, but keeping 4 worker pods running 24/7 is wasteful when the cluster is idle. Autoscaling with minReplicas: 1, maxReplicas: 6 would let workers scale to zero-of-what's-needed when the cluster is quiet and up to 6 during active use.

Anything else?

No response