Deploy images directly from the build Machine #803

Parent

Build runner spec (#798)

What to build

Connect the completed selected-Machine Build result to Direct Image Transfer and ordinary Deploy. This is the first complete remote build → application path. Serve from the complete build Machine and preserve exact image identity, including when several Services or clients use the same requested tag.

Acceptance criteria

• Support explicit selected-Machine execution for deploy and make it consume the remote Build result rather than inspecting the image in the client's Docker store. Keep normal standalone build local-to-its-result-location, explicit Direct Image Transfer, and explicit registry publication distinct. Validation-only work produces no image transfer or Deploy.
• Deliver the completed immutable image from its actual build Machine using the existing serving/transfer primitives, without downloading the full image to the client or publishing it to an external registry. Bind delivery to exact content across tag reuse. For this slice, use the complete build Machine as source rather than tag-only arbitrary peer selection.
• Check single-platform compatibility with application destinations before application mutation. Report transfer successes, failures, and omissions per Machine without pretending fan-out is atomic. Preserve image-store/capability errors rather than guessing at success from a tag.
• Build all selected Services and required Service image contexts in dependency order; bind each consumer to the completed dependency output even when their execution locations differ. Reuse image transfer/serving where needed instead of assuming a local tag can be resolved from a registry. Preserve selection, profiles, cycle refusal, tags, and immutable context/authentication rules.
• Finish every required Build before any Service Container, Hook Container, or application-volume mutation. Failure or cancellation prevents those application changes and identifies dependent/remaining work as unattempted; completed images and cache can remain. Keep prepare-once Deploy, ordinary/Data Loss Confirmation, existing placement and Machine-local admission, and partial Deploy results.
• Use rung-2 client tests for no local image inspection, exact-content binding across tag overwrite, failed-build mutation sentinels, dependency output binding, and per-Machine transfer outcomes. Add a registered rung-4 real remote Dockerfile build, Machine-to-Machine delivery and Deploy, with external-registry fallback disabled and a real Service-context dependency. Verify the image can run on its destination.

Blocked by

• #802 — Build a Dockerfile on an explicitly selected Machine