feat: add OCI artifact export via postprocessor

[sozercan]

Summary

Add support for exporting OCI artifacts through a postprocessor model, following the architecture discussed in #6393 (comment)

Instead of implementing artifact export as a gateway exporter at the same level as built-in exporters, this models it as a postprocessor step that runs between the build and export phases:

1. A frontend runs a build and signals artifact metadata on the result via well-known metadata keys (containerimage.artifact, containerimage.artifact.type,
   containerimage.artifact.config.mediatype, containerimage.artifact.layers)
2. The ArtifactProcessor detects this metadata and invokes SolvePostprocessor(), which runs the artifact.v0 frontend in a standard frontend sandbox
3. The artifact frontend assembles an OCI layout from the input files via LLB operations (no shell scripts, no file proxying)
4. The transformed result replaces the original, and any built-in exporter (image, OCI, local) handles the output

This enables frontends to produce OCI artifacts that can be pushed directly to registries, exported as OCI tarballs, or written to local directories — without the frontend needing to implement any export logic itself.

Design

• Postprocessor chain — solver.go gains a Processor type and a loop that runs registered processors between build and export. The artifact processor is one such processor.
• Frontend sandbox — The artifact.v0 frontend is registered via forwarder.NewGatewayForwarder, the same mechanism used for dockerfile.v0. No custom execution paths.
• No exporter interface changes — The Exporter/ExporterInstance interfaces remain unchanged. No llbBridge, executor, or FrontendResult parameters added.
• No proto changes — No new gRPC RPCs or wire protocol additions required.
• Provenance — Full SLSA provenance tracking via new Postprocess []Parameters field in both v0.2 and v1.0 formats.
• Path validation — Layer paths from frontends are normalized and validated to prevent path traversal.

Validation

This has been tested end-to-end with AIKit, which uses this to package HuggingFace models as CNCF ModelPack OCI artifacts:

docker buildx build \
  --build-arg BUILDKIT_SYNTAX=docker.io/sozercan/aikit:pr748-448e292-rootlayout2 \
  --target packager/modelpack \
  --build-arg source=huggingface://Qwen/Qwen3-0.6B \
  --build-arg name=qwen3-0.6b \
  --build-arg output_mode=artifact \
  --output type=image,name=docker.io/user/qwen3-0.6b:latest,push=true \
  -<<<""

The AIKit integration PR: kaito-project/aikit#748
Buildkit image: docker.io/sozercan/buildkit:oci-layout-passthrough-b6f47d1e0
Resulting artifact examples:

• without attestations: https://oci.dag.dev/?image=docker.io%2Fsozercan%2Fqwen3-0.6b%3Amodelpack-448e292
• with attestations: https://oci.dag.dev/?image=docker.io%2Fsozercan%2Fqwen3-0.6b:modelpack-e7e4584-prov-sbom

[tonistiigi]

This doesn't seem to have much to do with #6393

Instead, it looks like most of the changes are in the container image exporter and the new built-in "artifact" frontend.

If you want to work on the (external) postprocessors you can confirm your design in #6393 and make sure it covers the example use cases, eg. ability to write both artifact conversion(eg iso), deploy based postprocessors. We should also have a plan how this might be used to for reproducibility converters and sbom in the future to make the current solutions more flexible. This shouldn't contain any new "artifact" exporting.

If you want to support non-image OCI artifacts in current builtin exporters then that should have a separate design issue, where we can confirm the protocol between the build result metadata and the exporter. To make these use cases efficient don't we also need some sort of "non-tar" storage type so we can pull these artifacts, change their composition and then export (unlike image layers, you can't run containers on top of them of course).

CI is also failing, but that doesn't look like the biggest issue atm.