W3.6: an engine-neutral OCI-layout image store, oci-layout parents, and a tag-free engine import #36

W3.6 — one BuildKit build path: an engine-neutral OCI-layout image store

Part of opencharly/opencharly#481 (BuildKit as charly's one image builder).

Measured gap

The build drive still produces an engine-specific artefact and bridges it with a tag step:

• candy/plugin-build/buildkit.go exports type=oci,dest=<stage tar> with no name annotation, then
  buildkitdrive.LoadExport does load → tag <id> <ref> → inspect against the run engine. The tag step is
  only needed because the archive carries no io.containerd.image.name.
• There is no engine-neutral image store: a box-on-box build resolves its parent through the local registry
  mirror (DaemonOptions.RegistryMirror), which is the path Adopt BuildKit as charly's ONE image builder — 13 legs, retiring the podman/buildah + docker/buildx build drivers opencharly#481 describes as the #481 403,
  and the build registry mirror is read by the drive but only reaches a buildkitd that starts AFTER it is set #35 measures the daemon-order defect in it.
• spec.BuildRequest has no engine field and candy/plugin-build/ensure.go still execs the literal podman
  (podman pull, podman tag) instead of the engine capability table.

Spike (measured on a, 2026-10-23, buildkit 0.34.1 / podman 6.1.4)

• buildctl ... --output type=oci,name=<full-ref>,dest=x.tar writes, in index.json:
  io.containerd.image.name=<full-ref>, org.opencontainers.image.ref.name=<tag only>,
  org.opencontainers.image.created=<rfc3339>. podman load -i x.tar lands it tagged, no tag step.
• The negative control — the same build without name= — lands Loaded image: sha256:… untagged/dangling.
• A child solved with --oci-layout charly=<store> --opt context:<base-ref>=oci-layout://charly@sha256:<manifest>
  succeeds while the base ref's registry is unreachable; the same child without the override fails with
  dial tcp: lookup ghcr.invalid: no such host. That is the box-on-box proof: the layout, not the registry,
  supplies the parent.

Scope of this change (plugin-build)

1. Export each built image with name=<FullTag>; write the archive into the charly image store — one OCI
   layout at $XDG_DATA_HOME/charly/images/, one index.json, each manifest annotated
   io.containerd.image.name=<FullTag> and org.opencontainers.image.created — and keep it as the canonical
   artefact.
2. Materialise from the annotated archive into the run engine without a tag step, verifying the ref resolves
   through the engine capability table (no engine word literals in the code path).
3. Wire buildkitdrive.Build.OCILayouts (sdk#433, tag v0.2026296.803) plus the named-context option so a
   parent present in the charly store is solved from oci-layout://charly@<digest>; the registry is a fallback
   only when the parent is absent locally.
4. Keep --push as the second output (type=image,push=true).

Out of scope here, filed separately (cross-repo)

• charly box build --engine needs spec.BuildRequest.Engine + a plugin-box flag — filed in plugin-box/spec.
• --tag > box tag > defaults.tag > auto cannot be implemented in the drive alone: plugin-box pre-fills
  req.Tag with the computed CalVer, so an explicit --tag cannot be distinguished from auto — filed in plugin-box.
• charly clean (keep_images) pruning of the charly image store lives in plugin-clean — filed there.
• The ResolvePodEngine/ResolveContainerdTarget resolver is feat(deploykit): the W3.1 selection resolvers — engine, VM backend, containerd target sdk#457 (open, untagged); this change
  keeps the existing resolved-run-engine selection path and does not add a second selector.

Acceptance

• OCI annotation proven with its negative control (both directions).
• A box-on-box build with the parent in the charly store and the registry unreachable.
• The layout imports into at least one engine.