fix: build registry auth and Docker image OCI compatibility

[hiroTamada]

Summary

• Add 10.100.x.x subnet to allowed VM networks for registry auth fallback
• Convert Docker v2 mediatypes to OCI equivalents in image unpacking
• Explicitly set DOCKER_CONFIG env var for buildctl
• Update documentation to use docker buildx with oci-mediatypes=true

Problem

1. Registry auth failing with 401: Remote servers configured with 10.100.x.x subnet, but IP fallback only allowed 10.102.x.x, causing builds to fail when pushing to registry.

2. Docker images incompatible: Images from Docker Hub use Docker-specific mediatypes (e.g., application/vnd.docker.container.image.v1+json), but umoci requires OCI mediatypes for layer unpacking, causing "config blob is not correct mediatype" errors.

Changes

lib/middleware/oapi_auth.go

// Before
return strings.HasPrefix(ip, "10.102.")

// After  
return strings.HasPrefix(ip, "10.100.") || strings.HasPrefix(ip, "10.102.")

lib/images/oci.go

Added convertToOCIMediaType() to convert Docker v2 mediatypes to OCI equivalents.

lib/builds/builder_agent/main.go

Explicitly set DOCKER_CONFIG=/home/builder/.docker for buildctl.

Test plan

• Tested build endpoint on remote server with 10.102.x.x subnet
• Verified end-to-end: build → create instance → create ingress → test app endpoints
• All endpoints (/health, /registry, /) responded correctly

---

Note

Focuses on OCI compatibility and registry auth reliability.

• Image handling: convert Docker v2 mediatypes to OCI in lib/images/oci.go so umoci layer unpacking works
• Builder agent: set DOCKER_CONFIG=/home/builder/.docker when running buildctl-daemonless.sh to use registry credentials
• Auth middleware: expand internal VM IP fallback to include 10.100.x.x for /v2/* registry requests
• Docs: update build instructions to docker buildx with oci-mediatypes=true and switch example image names to onkernel/*

^{Written by Cursor Bugbot for commit 223351d. This will update automatically on new commits. Configure here.}

[rgarcia]

this feels a little fragile ... should it depend on config (e.g. config.go has subnet / bridge config that determines this prefix)