trunk/5082fb922f1683b096a2393e601a185ee66d203b: Use dtensor-build's docker-image output in dtensor-test (#185158)

dtensor.yml passes the bare image name

ci-image:pytorch-linux-jammy-cuda13.0-cudnn9-py3-gcc11 to

_linux-test.yml. The test-osdc job uses that value verbatim as the pod's

container.image, so the OSDC pool tries to resolve the bare name against

its default registry, where the image isn't published. The pod sits in

ImagePullBackOff for the full 7200s pod-creation timeout and fails. Over

the last 3 days this produced 61/61 OSDC dtensor-test failures (~89pp

OSDC-only failure-rate delta on the dtensor shard, the largest remaining

contributor to the OSDC vs EC2 shadow-mode failure-rate gap).

Reference dtensor-build.outputs.docker-image instead. Post #184665 the

OSDC build job emits a fully qualified ECR URL

(308535385114.dkr.ecr.us-east-1.amazonaws.com/pytorch/...) that the OSDC

pool can pull. This matches the idiom every other caller of

_linux-test.yml uses (pull.yml, trunk.yml, periodic.yml, inductor.yml,

torchtitan.yml, ...); dtensor.yml was the only test caller passing a

bare name.

The alternative was to hardcode the full ECR URL inline like

dynamo-unittest.yml does, but that duplicates the registry host in yet

another workflow and drifts from the rest of the test callers. The

build-output reference is the structural fix.

_linux-test.yml, _docs.yml, and _linux-test-stable-fa3.yml still have a

plain image: ${{ inputs.docker-image }} in their OSDC code path and

rely entirely on callers passing a fully qualified URL. A separate

change should mirror the ECR-URL construction _linux-build.yml got in

#184665 so future callers can't repeat this mistake.

Test Plan: push ciflow/dtensor on this commit and confirm the OSDC

dtensor-test pod pulls the image and runs to completion.

Authored by Claude.

Pull Request resolved: #185158

Approved by: https://github.com/wdvr