core: export cache entries through a general hidden engine.localCache._export - #15127

The engine image's pre-warmed cache was made by a hidden field that only the image's build called, Query._engineImageBundle. It picked each result's parts from a table of types, and reached into a Git module source for its checkout. This replaces it with a general export, engine.localCache._export(results, forcedCompression), which the image's build now calls like any other caller. Nothing changes for users.

What the export does. It writes any results' cache entries to a directory as bundle.json plus their blobs. That is the format the engine merges from the image at start, which is unchanged.

• Each result carries its own parts, read from its record, with no list of types. A container brings its image config, filesystem and exec metadata, because those are its parts.
• A result with no parts of its own carries the parts of the results it holds instead. A Git module source has none, so it carries its checkout's.
• What made a result, such as the execs of a build, travels as records only. A lookup of the result reads its own data, not theirs.
• It evaluates each result and every part it declares before exporting, and fails if a part is still incomplete afterwards.

Removed:

• Query._engineImageBundle and its type table.
• dagql.Cache.ExportImageBundle. It is now dagql.Cache.ExportBundle, which has no image-specific rules.

Unchanged:

• The engine's merge at start, from the image's fixed directory.
• The image's entries are never sent to the Cloud.
• Module._prebuild and Module._runtimeImage are kept. Their descriptions now present them as a general capability: a module's runtime for a given platform, built without running it.

The built-in Go SDK's shared dependency calls, shipped in the image. The Go SDK now builds every module runtime with dagger/go's sharedImports set to what generated code imports (distconsts.GoSDKSharedImports; dagger/go #104). engine-image-entries builds its seeds with the same list. It exports the two shared dependency calls' results through engine.localCache._export. Each is a module object holding package builds, and the export carries its record and the files and directories it holds.

A Go module's first build on a fresh engine used to look up each of ~450 packages one by one. Now it finds the standard library's call and the generated code's call whole, and looks up only its own other packages. A module that requires newer versions of the base modules still finds the standard library's call.

Measured on one 16-CPU amd64 machine, against main with dagger/go #104's other commits:

• 0.3–0.5 s faster idle, and 0.7 s faster with five loads at once;
• about 950 fewer API requests per first build;
• half the CLI's CPU;
• the image is 12 MB larger compressed (639 → 651 MB).

Tests: TestGo/TestRuntimeFindsSharedDependenciesInImage runs in test-module-runtimes with the image's entries, and cmd/engine-image-entries checks that the list covers what codegendeps pins. The built-in Go SDK's dagger/go pin and the workspace's go-sdk pin move together. The workspace's go-sdk pin is go-sdk v1.6.0 plus one commit that points its generated entrypoints at the same dagger/go as the built-in Go SDK, as the image's build requires. Both dagger/go pins follow dagger/go #104, which is still a draft, and move again to its final head before this merges.

Version gate: _export is new after v1.0.0-beta.27, so it is served only to views from v1.0.0-beta.28 on, as other APIs are gated to the version that first serves them.

Known limit: files a container mounts with withMountedFiles are results it holds, not parts of its own, so they travel as records only. The previous field didn't carry them either, and the image ships no such container.

Measured on one m8gd.4xlarge, comparing main 8376266 with this change. Each arm was built as a full engine image with its entries, and each run was a fresh engine running dagger -W github.com/dagger/dagger@83762668d8 check -l, in 4 interleaved pairs:

Tests, in RemoteCacheTransferSuite, which CI runs with the image's entries:

• Exporting an exec container carries all three of its parts.
• Exporting a directory an exec wrote carries only the directory's data, with the exec as a record.
• Exporting a Git module source on its own carries its checkout's data.

Every dev engine build also exercises the export, because it builds the image's entries with it.