Run Slurm generation without a client image using a versioned vLLM serving image #969

Objective

After pip install "data-designer[slurm]" and one-time Slurm profile setup, users should need only a serving image to run generation. The Data Designer client and inference proxy should run from the installed Python environment (or a reproducibly staged equivalent on the allocated node), with no separate client image or client.image declaration.

First-time user flow

For the currently supported vLLM backend, a user selects a versioned vllm/vllm-openai Docker image (or supplies a digest-pinned OCI reference) through the CLI. The CLI imports it to SQSH, inspects it, and registers it. An existing compatible SQSH remains an alternative. The user then runs data-designer slurm execute without manually running Docker or Enroot or preparing a Data Designer client image.

A version tag must be resolved and recorded as an immutable digest before import; import must use that digest. Preserve the existing digest-pinned OCI and SQSH registration paths.

Scope and implementation constraints

• Remove the experimental generation client-image requirement rather than maintaining dual client modes. No migration path is needed.
• Execute the client and proxy from the installed environment, or stage an equivalent exact environment for compute nodes. Validate availability, Python ABI, and package identity early with actionable errors.
• Keep the client execution boundary and content-addressed OCI-to-SQSH image lifecycle independent of the inference backend.
• Implement vLLM only in this issue. Keep vLLM-specific inspection, launch, readiness, and backpressure logic behind backend-specific boundaries so later SGLang or Dynamo integrations can supply their own adapters. Do not assume that every future deployment uses exactly one serving image or one serving process.
• Preserve existing proxy behavior, including 429 retry handling and the default max_waiting_requests=128.
• Do not add a generic Dockerfile/recipe builder or require a user-authored Dockerfile for this vLLM workflow. The starting point is a versioned vLLM Docker image.

Acceptance criteria

• A fresh pip installation and configured profile can execute a representative generation workflow with one registered vLLM serving image and no client image.
• The CLI accepts an explicit vLLM version or digest, resolves a version to an immutable digest before import, builds the inspected SQSH from that OCI image, and registers it.
• The existing digest-pinned OCI and compatible-SQSH paths continue to work.
• The user need not run docker buildx, enroot import, or a separate client-image preparation step.
• End-to-end output has an immutable winner, valid manifests/digests, the exact expected record count, and case-specific content assertions.
• CLI help, examples, and Slurm documentation show both the vLLM OCI and existing-SQSH routes, without client.image.

Context

PR #967 removed the separate proxy image but retained the generation client-image requirement. Today image add imports a digest-pinned OCI image to an inspected, registered SQSH; it rejects a version tag without a digest. This task removes the remaining client-image requirement and makes the vLLM version-selection flow reproducible.