ray(serve): drive dlc_major/minor_version LABELs from config ARGs

[Eren-Jeager123]

Problem

The Ray Serve Dockerfiles (docker/ray/Dockerfile.{cuda,cpu}) hardcoded the version LABELs as static text:

LABEL dlc_major_version="1"
LABEL dlc_minor_version="2"

The image configs (.github/config/image/ray/*.yml) set dlc_major_version / dlc_minor_version under build:, which the build-image action forwards as --build-arg. But since the Dockerfile declared no matching ARG, those build-args were silently ignored.

Consequences:

• Config and Dockerfile LABEL could drift (config said 0 while the LABEL said 2), and only the LABEL affects the released version (_resolve_release_version in DLContainersReleaseLogicPython reads dlc_major_version / dlc_minor_version off the built image).
• Editing the config's dlc_minor_version did nothing — only bumping the hardcoded LABEL cut a new minor. Confusing and error-prone.

Fix

Add ARG DLC_MAJOR_VERSION / ARG DLC_MINOR_VERSION and interpolate them into the LABELs, so the config build: block is the single source of truth:

ARG DLC_MAJOR_VERSION=1
ARG DLC_MINOR_VERSION=2
LABEL dlc_major_version="${DLC_MAJOR_VERSION}"
LABEL dlc_minor_version="${DLC_MINOR_VERSION}"

This matches the existing convention in docker/vllm/Dockerfile.amzn2023, docker/sglang/Dockerfile.amzn2023, and the new docker/ray-train/Dockerfile.cuda.

Verification

• resolve_build_args.py on ray/ec2-gpu.yml now forwards DLC_MAJOR_VERSION=1 and DLC_MINOR_VERSION=2, consumed by the new ARGs into the LABELs.
• No behavior change to the current release (config 1.2 == prior hardcoded LABEL 1.2) — this only removes the silent-ignore footgun. Pre-commit (dockerfmt etc.) passes.