feat(build): build and release a sandbox base image like every other compute type

[ItamarZand88]

Summary

A sandbox was the only compute resource alien build ignored, so a developer who
wanted one on their own image built and pushed it by hand while the CLI built
everything else. It now goes through the same two commands as a Worker.

When a developer runs the flow, three things happen:

1. alien build sees a sandbox declared from source and builds its base image
   from a Dockerfile, writing the same kind of artifact directory a Worker gets.
2. alien release pushes that directory and stores a location-free reference —
   the heart of this change, and the step that means nobody types a registry path.
3. The bundle layers the sandbox agent on afterwards, and AWS builds the MicroVM
   from it inside the customer's account, exactly as before.

This turns a hand-run docker push into alien build and alien release.

What was broken

Declaring a sandbox from source was refused at plan time on every platform, so
the base image had to exist before the stack did. Three places in the release
path knew about a worker, a container and a daemon but not a sandbox, so an
unchanged sandbox was pushed again on every release and --prebuilt carried a
path that no longer existed.

What I did

A sandbox base image is a root filesystem rather than a binary laid on a base
Alien picks, so it is built from a Dockerfile and the other toolchains are
refused by name. Source is now legal only where something can build it: on AWS
it is a declaration, and elsewhere the refusal names the platform, because there
the image is pulled as written and an unbuilt source would schedule a workload
with no image.

Two things a reviewer might look for and not find. The planner needs no sandbox
arm, because it asks which resources produce a host binary and a Dockerfile
build never does; that reasoning is now a comment where the missing branch would
be. And the preflight that refuses a resource linking a Live sandbox now names
the two ways out instead of stopping at the diagnosis.

Files touched

• crates/alien-build/src/lib.rs — the sandbox build branch, and the Docker-only
  toolchain policy.
• crates/alien-build/src/{merge,plan,toolchain/mod}.rs — a sandbox survives the
  partitioned CI merge; the new workload kind.
• crates/alien-cli/src/commands/release.rs — the three push-cache and rebase
  sites.
• crates/alien-core/src/resources/sandbox.rs — the per-platform source gate.
• crates/alien-preflights/ — the refusal message, and a test that drives the
  gate through the runner rather than calling the method.
• crates/alien-cloudformation/tests/ — the Live remote grant, now snapshotted.

How I tested

Ran the whole flow against real AWS rather than only in tests.

• alien build --platforms aws on a stack declaring a sandbox from source:
  produced .alien/build/aws/alien-sandbox-b492f56d/linux-aarch64.oci.tar.
• alien release --platforms aws: pushed it and stored the proxy reference. A
  second release did not push again, which is the cache fix working.
• Confirmed the generated bundle's Dockerfile reads
  FROM <account>.dkr.ecr.<region>.amazonaws.com/<project repository>:<tag>,
  so the image the developer built is the one the MicroVM is built on, and that
  the bundle landed in every regional store.
• cargo test across the touched crates: 1054 pass. Two pre-existing docker
  pull/export failures reproduce on a clean main.

This PR touches a grant and a permission set, so I walked the boundary:

• A sandbox reaching another project's repository: the manager derives the owning
  project from the deployment record rather than the stack and refuses anything
  else, pinned by a_refused_sandbox_base_image_leaves_the_grant_incomplete.
• The Live grant widening past its own image: the new snapshot pins an exact
  microvm-image:${AWS::StackName}-agents ARN with no trailing wildcard, so a
  sibling sandbox in the same stack is not matched. Its policy block is
  byte-identical to the Frozen one.
• The grant landing on a wider identity: asserted it attaches to the Remote
  Bindings role alone.
• Nothing turned up.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the previously reported Frozen source-sandbox failure is fixed and no new actionable defects were identified.

Summary

This PR adds AWS support for building and releasing Dockerfile-backed sandbox base images through the standard build pipeline.

• Builds sandbox source into OCI artifacts and rewrites the sandbox to reference the result.
• Adds sandbox support to merged build outputs, prebuilt-path rebasing, push caching, and pushed-image application.
• Allows source-backed sandboxes only on AWS and rejects them with the Frozen lifecycle before build work begins.
• Extends tests around platform gating, artifact merging, release caching, and remote sandbox permissions.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Sandbox Source declaration] --> B[Compile-time preflights]
  B -->|AWS + Live + Docker| C[Build OCI base image]
  B -->|Frozen or unsupported platform| X[Reject configuration]
  C --> D[Write sandbox artifact directory]
  D --> E[Release push/cache handling]
  E --> F[Private registry reference]
  F --> G[Sandbox bundle layers agent]
  G --> H[AWS builds MicroVM]

Loading

_{Reviews (3) · Last reviewed commit: "fix(preflight): refuse a sandbox built f..."}

[ItamarZand88]

@greptile review

[ItamarZand88]

@greptileai review

[ItamarZand88]

@greptile review