heavy-build sandboxes fail because the curated rootfs is not provisioned

[H3xept]

Summary

Creating a sandbox with the advertised heavy-build image and docker.enabled: true fails during Firecracker boot because the curated rootfs is not provisioned.

This blocks the documented Docker-in-Docker/full-Compose workload.

Reproduction

Request:

POST /v1/sandboxes
Content-Type: application/json

{
  "image": "heavy-build",
  "resources": {
    "cpu": 2,
    "memory_mb": 8192,
    "disk_gb": 32
  },
  "docker": {
    "enabled": true
  }
}

Observed behavior:

• the create call returns a generic HTTP 500
• a failed sandbox record is persisted
• the stored error reports boot failed: stage rootfs into chroot
• the failure is repeatable before any guest workload starts

Root cause

The image catalog and API advertise heavy-build, and the runtime resolves curated images from images/<key>/rootfs.ext4. However, the node provisioner only builds base and copies it for node-python; there is no heavy-build image recipe or staged rootfs.

The scheduler currently assumes curated images are locally available, so the request reaches Firecracker instead of being rejected at placement. The resulting boot error is then surfaced as a generic 500 after a failed sandbox record has been created.

Expected behavior

• node provisioning builds a real Docker-capable heavy-build rootfs
• Docker and Compose readiness are verified through the real API/Firecracker path
• nodes without the requested curated artifact are excluded from placement
• if no capable node is available, create returns a stable capacity error before persisting a sandbox record

Impact

base workloads are unaffected. heavy-build Docker-in-Docker workloads cannot start on nodes provisioned by the repository's current deployment path.