feat(chart): add opt-in enableInTreeAutoscaling support

[oren-openteams]

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.

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:

• 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)

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.

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.

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